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

[Liviu Ionescu <ilg@livius.net>]

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.


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.


regards,

Liviu