All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Michael Tokarev" <mjt@tls.msk.ru>,
	"Michael Roth" <mdroth@linux.vnet.ibm.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>, "John Snow" <jsnow@redhat.com>
Subject: Re: Python 3.5 EOL; when can require 3.6?
Date: Thu, 17 Sep 2020 17:24:15 +0200	[thread overview]
Message-ID: <37d8203d-e4f8-f9dd-828c-2d754a3695eb@redhat.com> (raw)
In-Reply-To: <20200917145512.GF1597829@redhat.com>

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

Also, some of our docker containers (tests/docker/dockerfiles/debian9*)
are still using Debian 9 and are now used in our Gitlab-CI for our MinGW
cross-compiler builds (I think also in the Shippable-CI, but I don't use
that, so not sure about that one) ... if we don't support Debian 9
anymore, we should update these to a newer version. Any volunteers?

 Thomas



  reply	other threads:[~2020-09-17 15:27 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16  7:43 Python 3.5 EOL; when can require 3.6? Markus Armbruster
2020-09-16  7:53 ` Philippe Mathieu-Daudé
2020-09-16  8:02   ` Thomas Huth
2020-09-16  8:16     ` Philippe Mathieu-Daudé
2020-09-16 13:53     ` Alex Bennée
2020-09-16 13:57       ` Daniel P. Berrangé
2020-09-17 14:53         ` Eduardo Habkost
2020-09-16  8:22   ` Andrea Bolognani
2020-09-16 15:09   ` Eduardo Habkost
2020-09-16  7:54 ` Thomas Huth
2020-09-16  8:33   ` Daniel P. Berrangé
2020-09-16  9:50     ` Thomas Huth
2020-09-16  9:54       ` Daniel P. Berrangé
2020-09-16  9:55         ` Thomas Huth
2020-09-16  8:31 ` Daniel P. Berrangé
2020-09-16 12:30 ` Peter Maydell
2020-09-16 13:30   ` Markus Armbruster
2020-09-16 14:00   ` Thomas Huth
2020-09-16 14:05     ` Daniel P. Berrangé
2020-09-16 14:57     ` John Snow
2020-09-17 14:10     ` Thomas Huth
2020-09-17 14:55       ` Daniel P. Berrangé
2020-09-17 15:24         ` Thomas Huth [this message]
2020-09-17 15:39           ` Daniel P. Berrangé
2020-09-17 15:41             ` Thomas Huth
2020-09-17 15:30       ` Markus Armbruster
2020-09-17 15:39         ` Thomas Huth
2020-09-17 15:42         ` Warner Losh
2020-09-17 16:07         ` Andrea Bolognani
2020-09-17 16:35           ` Daniel P. Berrangé
2020-09-17 17:02             ` Andrea Bolognani
2020-09-17 16:19     ` Eduardo Habkost
2020-09-17 16:33       ` Daniel P. Berrangé
2020-09-17 16:50         ` Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37d8203d-e4f8-f9dd-828c-2d754a3695eb@redhat.com \
    --to=thuth@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mjt@tls.msk.ru \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.