Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

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 <armbru@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