Open Stack

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