Paolo Bonzini <pbonz...@redhat.com> writes: > 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.
Even better: drop the '.', and stop worrying about having to wait for some arbitrary number to come up before you're allowed to do something ;)
