Add Version

[QuintinWillison]

As we do for our other code repositories, this repository should have:

• a version number
• a "release" procedure
• a change log

The version is going to effectively end up closely, or exactly, representing the Ably protocol version.

┆Issue is synchronized with this Jira Task by Unito

[QuintinWillison]

Perhaps under this issue, or perhaps under a new issue, we should also consider publishing some of the artifacts contained (or generated) here out to package repositories, in order to remove the need to use Git submodules downstream. 🤔

[QuintinWillison]

Work under this issue should include, or at least generate, work on ably-common-go so that the version is propagated to there.

See this internal pull request for context.

[QuintinWillison]

I already touched on this earlier in #142 (comment) but I remain of the mind that this repository does need a 'global version number', starting at 1.2.0 (our epoch) and roughly translating to 'Ably Version' when you boil it down (i.e. protocol / ecosystem foundations).

If that means moving sources that are not planned to be versioned into another repository (e.g. the JSON Schemas) then I think that's an acceptable cost to pay. It's a one-time job and doesn't change how they appear to downstream consumers.

WDYT, @lmars @paddybyers @jaley @stmoreau @owenpearson ?

[QuintinWillison]

This work is anticipated to be done by the SDK Team, probably myself, so I am adding the sdk label to indicate that.

[lmars]

@QuintinWillison apologies for not replying sooner. I question this statement in the description:

The version is going to effectively end up closely, or exactly, representing the Ably protocol version.

Could you perhaps expand on what about the contents of ably-common you think implies that the version should either closely or exactly follow the Ably protocol version?

[QuintinWillison]

We've had valuable discussion around this under this internal Slack thread started by @Morganamilo.

Within that discussion I stated:

I've had a niggling feeling, for some time, that I've shoehorned the features work into ably-common. Would anybody object to an assertive move / change of tack, whereby we create a brand new repository in the ably org that is simply called features (yes, not even a need for the superfluous, org-context-ignoring ably- prefix 😉). That is then the new home for the current contents of the features/ folder from ably-common.
At that point, protocol is - indeed - kept discrete, as its own concern.
And, I hope, nobody can object to that new repository being semantically versioned.

To which I added, in relation to what's on the roadmap after working on this ticket:

This new repository will include features.textile very soon (this issue). That document is the spec, in our current parlance. That spec is, I hope we can all agree, linked intrinsically with the user-facing surface area it supports, which is the canonical features list, which is going to be now housed also in this new repository.
Therefore, this new ably/features repository will include the spec, as well as this new canonical features list which is the user-facing / customer-facing representation of what it gives app developers when they include an SDK that conforms to it.

I'm currently waiting to see if anybody has any objections to that approach and will report back here if/when that new repository gets created. This issue, at that point, would then be moved to that new repository.

[QuintinWillison]

I notice this issue has been closed by the Unito sync bot, indicating that it was closed moved to 'done' (or another final state) in Jira. Inline with our GitHub First guidance, we should ideally be closing issues in GitHub, with a comment explaining why, so here I am to retrospectively add that comment... 😁

Having discussed this issue with @Morganamilo we agreed that there is no work to do here, because we have now moved the canonical features to its own dedicated ably/features repository. In that new location there is a version in package.json esablishing the epoch of 1.2.0.