Hi all, 0.MAJOR.MINOR versioning totally makes sense to me until we get to 1.0.0.
Just a couple of examples of releases we are doing this week: 1) tripleo-image-elements is bumped from 0.0.8 to 0.1.0 (we introduced a kind of incompatible change by switching Seed VM to neutron-dhcp-agent) 2) os-collect-config is bumped from 0.1.4 to 0.1.5 (we had Clint's patch reducing the default polling interval, which is not a bug-fix, but doesn't break backwards compatibility either) Thanks, Roman On Thu, Oct 31, 2013 at 4:44 AM, Robert Collins <robe...@robertcollins.net>wrote: > So, Chris and Roman have been pushing the cart of 'get all > [non-incubator] TripleO projects setup to do releases'. One > interesting thing came up is that we have no particular discussion > about how to choose versions. > > OpenStack as a whole seems to largely be semver compatible. For > TripleO I think we should follow semver fairly closely as we're going > to be tied into folks deployment cycle - being able to reason about > likely incompatibilities is a Good Thing. > > Where we haven't committed to a 1.0.0. release though, there is a grey > area, as semver basically says 'no semantic meaning at all there'. > Roman and I discussed this and we think that treating 0. versions as > 0.MAJOR.MINOR makes sense. So we would go from 0.0.X to 0.1.0 when we > do something incompatible with the prior 0.0.X version, and just > increment X otherwise. > > Thoughts? > > -Rob > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
