Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add supported platform section to README #481

Merged
merged 4 commits into from
Apr 5, 2018
Merged

Add supported platform section to README #481

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b7014c0
Add supported platform section to README
funkyboy Mar 2, 2018
3624f5d
Add note about fallback mechanisms
funkyboy Mar 2, 2018
8ed2cee
Update supported browsers
funkyboy Mar 29, 2018
b841e60
Update note about browsers
funkyboy Mar 29, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 22 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,30 @@

A Javascript client library for [Ably Realtime](https://www.ably.io), a realtime data delivery platform.

## Supported platforms

This SDK is compatible with the following platforms:

| Node.js | Browsers |
|----------|--------------------|
|   4 | IE 8+     |
|   6 | Chrome 64+ |
|   8 | Firefox 58+ |
|   9   | Safari macOS 11 |
|       | Safari iOS 11 |
|   | Chrome on Android 6|
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems overly restrictive -- I think we're underselling ourselves.

E.g. it makes it sound like we don't support firefox <=57, which may be rather off-putting for someone on, say, the current extended-support release (52). Or safari on iOS 10, or Chrome on Android 8, or the default browser on a Samsung phone, etc. etc. etc.

In reality we we do support all of those, in the sense that if someone found a bug in one of them we would put effort into reproducing and fixing it. We just don't test them on ci. But that's just for practical reasons -- if we could test every one of the thousands of platforms we consider 'supported' in that sense we would; since we can't, we test a selection of common ones. But that doesn't mean the sdk isn't compatible with others.

ISTM what's relevant to the customer is what we support, in that sense (what we'll accept and fix bug reports on), not what we happen to test in ci (which we reserve the right to change at any point without notice). So I'd suggest making the list of what we support be that. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SimonWoolf I have a similar concern.
We still have to extra time on the CI (before we max out the allowed session length). So we could add some older browsers like:

  • Firefox 52
  • Chrome TDB
  • Safari iOS10
  • Chrome on Android 4

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, we can discuss that in the CI issue. my main point for the purposes of this PR is that the libraries we support is a (large) superset of the libraries we test in ci, and we shouldn't imply otherwise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that addressed with my comments re fallbacks?

Copy link
Member

@SimonWoolf SimonWoolf Mar 5, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. ISTM that having a big table at the top saying "we're only compatible with firefox 58+, chrome on Android 4.0, ..." just because those are the versions we currently test in ci is just misleading in a way that isn't really anything to do with whether we have transport fallbacks (it's not like firefox 57 doesn't support websockets). Rather it's to do with whether we'll fix bugs reported against firefox 57. Which we will, even through we don't have that specific version in ci for practicality reasons. No?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @SimonWoolf's comments here. A visitor is probably not going to read the detail in reality, they are going to scan, see a table, and assume we don't support Opera or old versions, when we do.


We maintain compatibility and explicitly support these platform versions, including performing CI testing on all library revisions.

We do not explicitly maintain compatibility with older platform versions; we no longer perform CI testing on iOS7 as of version 1.0.13 (released on February 2nd 2018). Any known incompatibilities with older versions can be found [here](https://github.com/ably/ably-js/issues?q=is%3Aissue+is%3Aopen+label%3A%22compatibility%22).

If you find any issues with unsupported platform versions, please [raise an issue](https://github.com/ably/ably-js/issues) in this repository or [contact Ably customer support](https://support.ably.io) for advice.

We also support React Native, NativeScript and TypeScript. See below for more details.

## Version: 1.0.13

This repo contains the Ably Javascript client library, for the browser (including IE8+), Nodejs, React Native, NativeScript and Cordova.
The latest stable version of the Ably Javascript client library is `1.0.13`.

For complete API documentation, see the [Ably documentation](https://www.ably.io/documentation).

Expand Down