Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)

["Marc-André Lureau" <marcandre.lureau@gmail.com>]

Hi

On Wed, Mar 8, 2017 at 12:20 PM Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
>
> > libvirt suffered similar lack of clarity around when to bump major
> version
> > number as opposed to minor version. To address this we recently adopted
> the
> > rule[1] that major version number changes have no relation to features.
> The
> > major number is simply incremented at the start of each calendar year.
>
> I like the idea of time-based version numbering.  Changing the plan for
> 2.9 still is probably a bad idea given we have a 2.9 machine type
> already etc.
>
> But we can start changing things afterwards.  So we could start with 3.x
> after 2.9, and bump the major for the first release each year
> (libvirt-style).  Or we could use the year as major number and jump
> straight to 17.x (mesa-style).
>
> > From the POV of libvirt, I don't think saying that .0 releases have
> > incompatible changes is particularly useful in itself. What *is* useful
> > is to have a clear rule around a deprecation cycle. ie, a rule that says
> > a feature will be marked deprecated for 3 releases or 12 months, before
> it
> > is permitted to be removed/changed. If that were followed, there is no
> > need to batch up such changes in a .0 release IMHO.
>
> Yes, it's probably a good idea to deprecate things first.  When going
> with the 12 months rule it could be useful to batch things and do a
> yearly "spring cleaning" when the major is bumped.
>
>
What about deprecating GTK 2.0 ? SDL (1.2 or all?)

I suspect there are also a number of arm boards that are not regularly
tested and could be drop, who could tell?

-- 
Marc-André Lureau