Open Stack

Excerpts from John Garbutt's message of 2015-06-03 14:01:06 +0100:
> Hi,
> 
> (To be clear, this is a proposal to be discussed and not a decision.)
> 
> The version number can help us communicate that:
> * you can consume a milestone release
> ** ... but the docs and translations may not be totally up to date
> * you can consume any commit
> ** ... but there is no formal tracking of bugs and features in that commit
> ** ... but can still live upgrade from the previous release to any
> commit in the current release
> * if you need completed docs and translations, wait for the final
> liberty release
> * we only support upgrade between <N>.x and <N+1>.x
> ** to ensure we can do live upgrades, but with minimal technical debt over time
> ** http://docs.openstack.org/developer/nova/devref/project_scope.html#upgrade-expectations
> 
> The idea is to keep what we do today, but try and communicate what
> that is a little better. Making it clear you can consume the milestone
> releases, and indeed the master branch, if thats what you want to,
> while being clear about what you loose and/or gain over waiting for
> the final release and/or stable branch.
> 
> Given we are thinking Liberty is moving to semantic versioning, maybe
> it could look like this:
> * 12.0.1 (liberty-1) will have some features (hopefully), and will be a tag
> * 12.0.2.dev1 is the first commit after 12.0.1 and does not get a tag
> * 12.0.2.dev1234 would be the 1234th commit after 12.0.1
> * 12.0.2 (liberty-2) will also contain features
> * 12.0.3 (liberty-3) is focused on priority features (given the current plan)
> * 12.1 is Liberty release is just bug fixes on 12.0.3
> * 13.0.0.dev1 would be the first commit to open M

These numbers don't match the meaning of semver, though. Semver
describes clearly why you increment each part of the version number
[1]. We can't call it semver and then make up our own completely
different rules.

Doug

[1] http://docs.openstack.org/developer/pbr/semver.html