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

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

On Wed, May 02, 2018 at 02:03:14AM -0700, Liviu Ionescu wrote:
> On 2 May 2018 at 11:13:49, Thomas Huth (thuth@redhat.com) wrote:
> 
> > https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
> 
> Thank you, Thomas.
> 
> > It took quite a while to get a consensus on that policy, so I don't
> > think that we want to sacrifice that for semver.
> 
> ok, this might be a point.
> 
> thinking twice, I'm not sure it is a real sacrifice; I think that the
> problem here is the strict definition:
> 
> "The feature will remain functional for 2 releases prior to actual removal."
> 
> if it were:
> 
> "The feature will remain functional for _at least_ 2 releases prior to
> actual removal. "
> 
> or even better:
> 
> "The feature will remain functional for _at least_ 2 _major_ releases
> prior to actual removal. "
> 
> 
> it would allow to postpone incompatible removals to relatively seldom
> major releases, add new features during more often minor releases, and
> fix bugs during regular patch releases.
> 
> major releases can be scheduled every 1-2 years, for example, minor
> releases every 3-6 months, and patch releases when needed.

No, we do not want to extend the deprecation period further just so that
we can adopt semver.  We explicitly chose "2 releases", so that every
deprecation warning has the same lifetime - we don't want some deprecations
to be 4 months long, while other deprecation warnings are 1+1/2 years long.

> from a use perspective, I don't think that updating the deprecation
> policy would be objected, so that would not be perceived as a
> sacrifice; on the contrary, such a mechanism would allow both a
> faster/flexible release cycle, and give the users a more educated
> guess when it is time to upgrade; both beneficial.
> 
> for the developers/maintainers... I agree that it would require some
> more discipline and responsibility.
> 
> not to mention that even before semver, in most versioning schemes it
> was somehow expected that while the first version number remains the
> same, compatibility is more or less preserved.

Plenty of software has versioning schemes that are nothing like semver.
Any assumption that first version number changes mean incompatibilty is
a false one, unless the project has explicitly declared that to be the
case.  Calender based versioning is very widely used.

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 :|