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