Excerpts from Daniel P. Berrange's message of 2015-06-03 14:28:01 +0100: > On Wed, Jun 03, 2015 at 03:09:28PM +0200, Thierry Carrez wrote: > > John Garbutt wrote: > > > 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 > > > > The current thinking on the release management team would be to do > > something like this for projects that are still doing milestone-based > > development: > > > > * 12.0.0b1 (liberty-1) > > * 12.0.0b2 (liberty-2) > > * 12.0.0b3 (liberty-3) > > * 12.0.0rc1 (RC1) > > * 12.0.0 is Liberty release > > This kind of numberig is something I'd really like us to get away from > in Nova, as by including beta/alpha nomenculture, it is really telling > users that these releases are not to be deployed outside the lab. > > > I think assuming people can tell 12.0.1 is an alpha and 12.1 is a > > release that is just bug fixes over 12.0.3 is a bit crazy... > > > > The alternative would be to go full intermediary releases and do: > > > > * 11.1.0 > > * 11.2.0 > > * 11.2.1 > > * 11.3.0 > > * 11.3.1 (oh! that happens to also be the "liberty" release!) > > * 11.4.0 > > > > I don't think we can maintain an middle ground. > > What I think we're saying for Nova is that we're not going to change > the cadence of what we're releasing. ie we're still following the > milestone based development timeline. Instead we're trying to get > across that the milestone releases are none the less formal releases > you can deploy and/or base downsteam products on. > > Personally I like the idea of every release we do being fully equal > in status, but at least in the short term we'll have limitations > that some of the releases will not be synced with docs & translations > teams, so will not quite be at the same level. > > On IRC John also mentioned that the point at which we bump the > second digit in the semantic version is also the marker bouy at > which we remove deprecated config parameters, and/or merge / > drop database migrations.
That's not how I interpret the semver rules. If we consider removing a configuration option a backwards-incompatible change, that means incrementing the major version number (rule 8 from [1]). The second digit would be incremented when the deprecation is *started* (rule 7). 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