On 3 June 2015 at 15:37, Daniel P. Berrange <berra...@redhat.com> wrote: > 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.
So, I was trying to see how far I could bend SemVer before it broke. There appears to be consensus that I bent it too far, so thats cool. Thanks, John __________________________________________________________________________ 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