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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, May 02, 2018 at 12:43:10AM -0700, Liviu Ionescu wrote:
> On 2 May 2018 at 10:38:09, Cornelia Huck (cohuck@redhat.com) wrote:
> 
> > > > >> 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...
> > >
> > > It's just a matter of taste, but I think I'd prefer variant b).
> > That
> > > will bump the major release approx. every three years which
> > sounds like
> > > a good time frame for me.
> >
> > I think anything that keeps release numbers in ascending order
> > would
> > basically work :)
> 
> not really.
> 
> I suggest you use semantic versioning:
> 
> https://semver.org

No, not semver. It is not a good match for the way QEMU is handling
incompatible changes. Our deprecation policy lets us include incompatible
changes in *any* release. So with semver that would force a major version
bump on every release which is madness.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|