1.0 release #260
1.0 release #260
Conversation
|
|
Should we merge the |
|
No, because |
I just figured because the only thing in that branch that isn't in master is the authUrl response validation, and you've indicated in https://github.com/ably/infrastructure/issues/1017 that you'd like implementing in ably-js now (i.e. for 0.9/1.0 release). If you'd rather it be done in ably-js as a special case and kept out of the spec, that's completely fine, just wanted to make sure that was a deliberate decision and not an oversight |
Do not allow people to use the CDN without a major version so that we have the flexibility moving forwards to introduce breaking changes with major version releases.
Run command: $ git diff v0.8 master content/client-lib-development-guide/features.textile > content/client-lib-development-guide/versions/features-0-8__1-0.diff
mattheworiordan
force-pushed
the
master-1-0
branch
from
3f75377 to
5d87c9b
Compare
…ge per envelope Fixes #278
Fixes #247 Includes all mentioned updates at ably/ably-dotnet#89 plus loads of unmentioned ones.
|
@paddybyers @tcard @SimonWoolf if you do get a chance, please review my changes to the docs I have made tonight, see 5d87c9b...155fa73. Lots of fixes for inconsistencies and other issues we had open in this docs repo. I am merging this into |
|
|
||
| * If the channel is @initialized@ (i.e. no attempt to attach has yet been made for this channel), then calling @subscribe@ will implicitly attach the channel. However, regardless of the implicit attach outcome, the <span lang="default">listener</span><span lang="ruby">block</span><span lang="csharp">handler</span> will still be registered | ||
| * If @subscribe@ is called more than once with the same <span lang="default">listener</span><span lang="ruby">block</span><span lang="csharp">handler</span>, then duplicates will be registered. For example, if you @subscribe@ twice with the same <span lang="default">listener</span><span lang="ruby">block</span><span lang="csharp">handler</span> and a presence message is later received, the same <span lang="default">listener</span><span lang="ruby">block</span><span lang="csharp">handler</span> will be invoked twice | ||
| * The registered <span lang="default">listener</span><span lang="ruby">block</span><span lang="csharp">handler</span> remains active on the presence channel regardless of the underlying channel state. For example, if you call @subscribe@ when the underlying channel is @attached@ and it later becomes @detached@ or even @failed@, when the channel is reattached and a presence message is received, the <span lang="default">listeners</span><span lang="ruby">blocks</span><span lang="csharp">handlers</span> originally registered will still be invoked. Listeners are only removed when calling "@unsubscribe@":#unsubscribe or when the underlying channel is @released@ using the <span lang="default">@Realtime.channels.release(name)@</span><span lang="csharp">@Realtime.Channels.Release(name)@</span> method |
There was a problem hiding this comment.
default">@Realtime.channels.release(name
The js docs generally use realtime rather than Realtime for an instance of the client lib, Realtime is the constructor (ie var realtime = new Ably.Realtime)
There was a problem hiding this comment.
The js docs generally use realtime rather than Realtime for an instance of the client lib,
Well as far as I can tell, we haven't done either. We only use realtime.* in code example, never in documentation itself. I searched the docs now, cannot find one instance of that or channel.* etc either.
Unfortunately the issue here is in fact that we don't have docs for the Channels collection, see #251. I think I'm going to leave this as is until we address that problem and then we can use the pattern we have used in the docs such as "... if either @publish@ or @subscribe@ for the @channel@ is called ..."
| @@ -233,7 +233,7 @@ We're now ready to start consuming messages from the queue. There are "plenty of | |||
|
|
|||
| ```[json] | |||
| "dependencies": { | |||
| "ably": ">=0.9.0-beta", | |||
| "ably": "~1.0", | |||
There was a problem hiding this comment.
"~1.0"
I don't think this is right, assuming we want something that matches >= 1.0.0 && < 2.0.0 -- you want either ~1 or ^1.0; ~1.0 locks into the minor version
(similarly for the others)
There was a problem hiding this comment.
Well we previously locked into minor versions, I don't really see the harm, but sure I can change to ~1
| @@ -607,7 +607,7 @@ blang[android]. | |||
| ... | |||
| dependencies { | |||
| ... | |||
| compile 'io.ably:ably-android:0.8.7' | |||
| compile 'io.ably:ably-android:1.0.0' | |||
There was a problem hiding this comment.
Do we want to lock into the .0.0 patch version? At a quick google looks like gradle uses https://ant.apache.org/ivy/history/2.1.0/settings/version-matchers.html, so I think we should be able to specify 1.0+ or 1+ to lock into the minor or major versions resp
There was a problem hiding this comment.
Best practice is a matter of debate: http://blog.danlew.net/2015/09/09/dont-use-dynamic-versions-for-your-dependencies/
Last time we discussed it we decided to use a fixed version reference.
There was a problem hiding this comment.
I must admit @paddybyers I really don't see why we're special casing Java over every other library? The developer referencing the Java lib should decide if they want to lock to a specific version or not, however the documentation itself, unless we update it for every Java release, will simply encourage people to use old unpatched versions of the library. My vote is to add a note to say it's up to the developer to decide if they want to lock into a major, minor or patch release, but the docs should encourage a user to lock into the version that matches this documentation which is 1.0+
|
👍 |
@paddybyers @SimonWoolf @tcard this PR introduces version 1.0 ready for release when the libraries are ready. Note that: