qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Deprecation policy and build dependencies


From: Markus Armbruster
Subject: Re: [Qemu-devel] Deprecation policy and build dependencies
Date: Mon, 03 Jun 2019 14:26:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

John Snow <address@hidden> writes:

> On 5/31/19 3:24 PM, Eduardo Habkost wrote:
>> Long story short: I would really like to drop support for Python
>> 2 in QEMU 4.1.

The sooner, the better, as far as I'm concerned.

>> What exactly prevents us from doing this?  Does our deprecation
>> policy really apply to build dependencies?
>> 
>
> Normally I'd say it's only nice to also follow the depreciation policy
> for tooling as well to give people a chance to switch away, but with
> regards to Python2, I feel like we're in the clear to drop it for the
> first release that will happen after the Python2 doomsday clock.
>
> (So, probably 4.2.)

In addition to our feature deprecation policity, we have a "Supported
build platforms" policy (commit 45b47130f4b).  The most common holdback
is this one:

    For distributions with long-lifetime releases, the project will aim
    to support the most recent major version at all times. Support for
    the previous major version will be dropped 2 years after the new
    major version is released. For the purposes of identifying supported
    software versions, the project will look at RHEL, Debian, Ubuntu
    LTS, and SLES distros. Other long-lifetime distros will be assumed
    to ship similar software versions.

RHEL-7 has Python 3 only in EPEL.  RHEL-8 came out last month.  Unless
we interpret our policy to include EPEL, this means supporting Python 2
for some 16 months after upstream Python retires it.  My personal
opinion: nuts.

I didn't bother checking Debian, Ubuntu LTS and SLES.

For hosts other than Linux, we're less ambitious.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]