Re: [Qemu-devel] release retrospective, next release timing, numbering

[Cornelia Huck <cohuck@redhat.com>]

On Mon, 30 Apr 2018 11:33:12 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Fri, Apr 27, 2018 at 04:51:03PM +0100, Peter Maydell wrote:
> > Hi; I usually let people forget about releases for a month or
> > so before bringing this topic up, but:
> > 
> > (1) do we want to call the next release 2.13, or something else?
> > There's no particular reason to bump to 3.0 except some combination of
> >  * if we keep going like this we'll get up to 2.42, which starts to
> >    get silly
> >  * Linus-style "avoid being too predictable"
> >  * triskaidekaphobia
> > but maybe we should anyway?  
> 
> I'm in favour of changnig the major version to 3.0, but when we do
> so we should also define a clear rule we can follow for major version
> bumps, so we don't have the same silly debate for how we pick 4.0,
> 5.0 etc.
> 
> Given, that we have a clear deprecation process now, my view is that
> we should formally declare that major version numbers changes are
> meaningless. As soon as you try to assign special meaning to major
> version changes, you open the door to endless debate about whether
> a particular set of changes is meaningful enough to justify the
> major version change, leading to eventually 2.42. 

I agree.

> 
> Two possible options
> 
>  a) Bump major version once a year, so we'll have 3.0, 3.1, 3.3,
>     4.0, 4.1, 4.2, 5.0, ...etc  We missed the first release this
>     year, so we would only have 3.0 and 3.1 this year.
> 
>  b) Bump major release when minor version gets double-digits.
>     eg 3.0, 3.1, ...., 3.9, 3.9, 4.0, ...., 4.9, 5.0...
> 
> Personally I'd go for (a). If we do this, it doesn't preclude
> us from just happening to do some releases that are backwards
> incompatible. Our deprecation policy has provided us a way to
> have a backwards incompatible change in ANY release we make.
> We just have to ensure people are forewarned of what's coming.

If we bump the major version each year anyway, why not go the whole way
and use 2018.1, 2018.2, ... (or even <year>.<month>)? The nice thing
about that is that you can see at a glance when the release took place.
The drawback is that stable updates might look a bit awkward, but I
don't think that's too bad, as we don't do multiple stable branches.

> 
> If it was an incredibly large & disruptive incompatible change,
> we might none the less choose to align its arrival with a major
> version bump. That's ok. We simply do not require that a major
> version change has to have a major incompatibility.

I'm not really in favour of that. "The major version means nothing
special, except when it does"? Also, cue the "is this change disruptive
enough?" discussions :)