On 2018-05-02 09:59, Daniel P. Berrangé wrote: > On Wed, May 02, 2018 at 12:43:10AM -0700, Liviu Ionescu wrote: >> On 2 May 2018 at 10:38:09, Cornelia Huck (coh...@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.
FWIW, I think that just means that our deprecation policy is weird. As a developer, it's great, of course. You can break everything, just put up a heads-up two versions in advance. But I'm grateful I'm not a direct user of qemu (i.e. without libvirt). I imagine it to be pretty stressful if I have to check on every (or every second...) release that qemu doesn't show up new deprecation notices for something I'm using. Maybe it would make sense to collect things we want to deprecate and then have a major release every year where we do that deprecation. As a user, I'd much prefer that to the possibility of everything changing all the time. Max
signature.asc
Description: OpenPGP digital signature
