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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev