Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machines pc-0.10 to pc-0.15

[Daniel P. Berrange]

On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote:
> 
> 
> On 10/05/2017 16:47, Thomas Huth wrote:
> >> So while we can delete pc-0.12, we can't delete associated features needed
> >> by pc-0.12, without complicating RHEL's ability to create its back-compat
> >> machine types. Downstream would have to un-delete the features.
> >
> > So I guess this is why Paolo said that pc-0.12 is still in "use" ... I
> > think removing pc-0.12, but not removing rombar=0 will cause confusion
> > in the upstream code base sooner or later,
> 
> I agree.
> 
> > so I guess we should rather
> > keep the pc-0.12 machine until we can get rid of it together with the
> > rombar code. We should still mark it as deprecated, of course.
> >
> >> I think tieing removal to major versions is a mistake, unless we're
> >> going to set a fixed timeframe for delivery of major versions. ie if
> >> we gaurantee that we'll ship a new major version every 18 months, that
> >> gives people a predictable lifetime.  If we carry on inventing reasons
> >> for major versions at arbitrary points in time, it makes it difficult
> >> to have any reasonable forward planning.  It is more users friendly if
> >> we can set a clear fixed timeframe for machine type lifecycle / eol
> >
> > IMHO we should have a new major release after we've reached a .9 minor
> > release, but so far it seems like I'm the only one with that wish...
> 
> I actually like that, but then you've pretty much guaranteed that you
> _cannot_ remove anything deprecated until 4.0.  You and Daniel aren't
> disagreeing as heavily as it seems, I think.

I don't think we should tie removal of features to version numbers. IMHO
we should just increment the first major digit on a fixed time scale,
either once a year, or whenever we get past .9.

For removal of features, IMHO, the only important thing is to give users
deprecation clear warning for 2-3  releases, and ensure feature detection
works well. As long as that is done, there shouldn't be any need to batch
them up for "major" releases. From libvirt POV, batching up removal to
major releases is not beneficial. Batching to major releases gives a very
inconsistent timeframe for removal too - somethign fdeprecated in .1
release may live on for years,  until the next $major.0, while something
deprecated in a .9 release can be killed in 4 months. I much prefer to
see a consistent deprecated for 2 releases / 8 months, then deleted
regardless of feature.

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