On 2 May 2018 at 11:13:49, Thomas Huth (th...@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