Open Stack

On 3 June 2015 at 15:37, Daniel P. Berrange <berrange at 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