Share session accross Ably clients

[jdavid]

Fixes #133

[paddybyers]

LGTM, thanks

[jdavid]

I still can't merge, I see this message:

Merging is blocked
The base branch restricts merging to authorized users.

[paddybyers]

OK, sorry, I wasn't paying enough attention.

PRs need to be made against develop. When we make a release, then we fast-forward master to the release sha, which is typically just the head of develop. So it's wrong to create a PR to merge to master - there shouldn't be a merge commit created, and no sha in master that isn't also in develop.

@jdavid I've updated the branch protection so that you can push to master, and I've updated master for this release. I'm closing this PR now.

[jdavid]

Okay, in issue #133 @mattheworiordan asked me to make a minor v1.0.2 release, but now I understand the next release will be v1.1.0

In general this procedure as is doesn't allow to have an stable branch with minor bug fix releases, and a development branch for future major releases. O am I missing something?

[paddybyers]

If we're maintaining a branch for 1.0.x releases, then create a branch 1.0.x, tag at the point that you make a given release v1.0.2, and don't merge into master.

Is there anything now in master that's not appropriate for 1.0.x ?

[jdavid]

Okay, there was already a 1-0-master branch so I'll use that.

However, if master represents the state of the next major release, I don't get why the develop branch; I don't see a develop branch in ably-ruby either.

With the merge (fast-forward actually) from develop to master you did earlier, now the master branch contains the push and idempotent stuff, what will become v1.1 if I did not miss something.

[paddybyers]

Here's some notes from the process we use internally. The distinction between master and develop is that the only commits to appear in master are the actual releases; interim PRs can be landed in develop between releases.

Ruby has not been updated to use this model, but most of the other library repos are.

Process detail: branches

Branches are created and named as follows.

master: at all times this points to the latest stable and deployed version.

develop: this contains all completed work that is intended for the next release. By default, PRs are made relative to develop, and are landed in develop once approved. The HEAD of develop is the default point at which to create a new feature branch or integration branch for new work.

release-<identifier>: this designates a release branch. Previously, for realtime, these were named for-deploy-. A release branch is created when moving to verify and deploy new code. <identifier> is usually a date but different repos, or specific circumstances, might have identifiers based on a numbering scheme for releases.

integration-<descriptive name>: this designates an integration branch. This is a long-running branch on which a team can collaborate for development that is not intended for the next release or, for other reasons, is to be kept separate from develop. Having an integration branch enables multiple PRs to be raised in the course of development, with those being incrementally landed as development proceeds. <descriptive name> should be meaningful and can include an issue id or other specific identifier as appropriate.

feature-<descriptive name> (or simply <descriptive name>). This designates a feature branch. This is a branch for a specific and self-contained item of work, and is branched from develop or an integration branch. should be meaningful and can include an issue id or other specific identifier as appropriate.

[mattheworiordan]

@paddybyers can we add details on the branching strategy we follow to our docs repo, which already includes lots of documentation for our client lib developers? The Wiki docs we have are private and not suitable? I'll raise an issue.

[coveralls]

Coverage remained the same at ?% when pulling 5cf73c3 on fix133 into ef4aa01 on master.