Open Stack

On Wed, Jun 03, 2015 at 10:26:03AM -0400, Doug Hellmann wrote:
> 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).

If this doesn't match semver, then don't call it semvar versioning.
We should do what's right for the nova project, rather than try to
fit with an arbitrary set of versioning rules defined elsewhere.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|