All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Thomas Huth <thuth@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	Markus Armbruster <armbru@redhat.com>,
	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:33:15 +0100	[thread overview]
Message-ID: <20200917163315.GL1597829@redhat.com> (raw)
In-Reply-To: <20200917161919.GO7594@habkost.net>

On Thu, Sep 17, 2020 at 12:19:19PM -0400, Eduardo Habkost wrote:
> On Wed, Sep 16, 2020 at 04:00:14PM +0200, 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.
> 
> Thank you very much for the summary.  I've added this info to
> https://wiki.qemu.org/Supported_Build_Platforms
> 
> Has anybody been able to find information om SLES Python
> versions?  I can't find this anywhere.

It is slightly tedious, but I was pointed at

  https://scc.suse.com/api/package_search/products

where you find the product ID.

eg SLES 15  is ID 1609

which you can plug into

https://scc.suse.com/api/package_search/packages?product_id=1609&amp;query=python

and that somes some package names like "libpython3_6" so 3.6.5
looks like a match,

This looks like it matches openSUSE Leap 15, which suggest we
probably don't need to look at SLES directly.


SLES 15 was released in July 2018, so with our 2 year overlap for the
previous release, we can consider SLES 12sp2 unsupported from this
release cycle.

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



  reply	other threads:[~2020-09-17 16:43 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
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é [this message]
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=20200917163315.GL1597829@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@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.