On 17/09/2020 17.39, Daniel P. Berrangé wrote: > On Thu, Sep 17, 2020 at 05:24:15PM +0200, Thomas Huth wrote: >> On 17/09/2020 16.55, Daniel P. Berrangé wrote: >>> On Thu, Sep 17, 2020 at 04:10:55PM +0200, Thomas Huth wrote: >>>> On 16/09/2020 16.00, Thomas Huth wrote: >>>>> On 16/09/2020 14.30, Peter Maydell wrote: >>>>>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <arm...@redhat.com> >>>>>> wrote: >>>>>>> We require Python 3.5. It will reach its "end of life" at the end of >>>>>>> September 2020[*]. Any reason not to require 3.6 for 5.2? qemu-iotests >>>>>>> already does for its Python parts. >>>>> [...] >>>>>> The default should be >>>>>> "leave the version dependency where it is", not "bump the version >>>>>> dependency as soon as we can". >>>>> >>>>> OTOH, if none of our supported build systems uses python 3.5 by default >>>>> anymore, it also will not get tested anymore, so bugs might creep in, >>>>> which will of course end up in a bad experience for the users, too, that >>>>> still try to build with such an old version. So limiting the version to >>>>> the level that we also test is IMHO very reasonable. >>>>> >>>>> Let's have a look at the (older) systems that we support and the python >>>>> versions according to repology.org: >>>>> >>>>> - RHEL7 / CentOS 7 : 3.6.8 >>>>> - Ubuntu 18.04 (Bionic) : >= 3.6.5 >>>>> - openSUSE Leap 15.0 : >= 3.6.5 >>>>> - OpenBSD Ports : >= 3.7.9 >>>>> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer >>>>> - Homebrew : >= 3.7.9 >>>>> >>>>> ... so I think it should be fine to retire 3.5 nowadays. >>>> >>>> Sorry, I forgot to check Debian. If I got that right, Debian 9 still >>>> uses Python 3.5 by default. So I guess that means we can not deprecate >>>> Python 3.5 yet? >>> >>> FWIW, Debian 9 EOL was July this year, if you only count the regular >>> lifetime, not the LTS. >> >> Do we support Debian LTS? ... If not, we should maybe add a proper >> remark about that to our support policy...? > > I didn't define Debian situation very well in the support policy > because I didn't realize it had separate normal and LTS EOL > dates. I had originally thought it was LTS only. > > In libvirt we have since clarified the language I originally > wrote (and then copied to QEMU), to remove the LTS distinction. > Instead libvirt now says: > > "The project aims 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 or when the vendor > itself drops support, whichever comes first. In this context, > third-party efforts to extend the lifetime of a distro are not > considered, even when they are endorsed by the vendor (eg. Debian > LTS)." > > I'd suggest we copy this updated terminolgy into QEMU as it simplifies > the current language used.
Sounds good, could you (or Markus) please provide a patch? Thanks, Thomas