Re: Should we remove python 3.5 from our CI tests

Russel Winder <[email protected]> Sat, 21 Jul 2018 12:37:10 +0100
Newsgroups	gmane.comp.programming.tools.scons.devel
Message-ID	<[email protected]>
On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
> Pretty certain Gary's with me in saying,
> SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
> releases.
> Most likely through (at least) the end of 2018.

You can add me to agreeing with that.

> I know many who actively participate in SCons community live on the
> leading
> edge of OS and Python releases but many users do not.
> Also, there are still some rough edges to our Python 3 support. Until
> it's
> rock solid (and no one has found an issue for a while), dropping py
> 2.7
> would be unwise.

I see your finger pointing at me. :-)

We have had not dissimilar maintenance debates in the Apache Groovy
community, especially now JDK is updated every 6 months instead of
every 6 years. Clearly there is a need to support people using ancient
three year old systems. Debian Stable and Ubuntu LTS really set the
timescales here, and the Python versions. Except that Travis-CI appears
to think using the most ancient Ubuntu LTS they can is a good thing.

But then come the issues at the heart of the matter: If people are
using three or five year old platforms, will they be using the very
latest version of SCons? If they want the very latest SCons why can't
they install the very latest Python? If they are happy with the three
year old Python will they actually be happy with the three year old
SCons? If a distribution provides Python and SCons why is there any
interest in them updating anything?

Groovy used to have a "we must be totally backward compatible"
obsession that was over the top, especially for me. Over the last year
the policy has changed towards something much better, and which has
allowed Groovy to progress much better in a highly dynamic world.

OK so Java has the big difference that you distribute compiled
artefacts and there are only link time issues, whereas Python is
distributed as source so everything is compile time issues. But the
Groovy team have now begun to accept that "backward compatibility" can
be taken too far. For each major version of Groovy a lower limit is now
set and if people are not prepared to update their Java, then they have
to use the last version of Groovy that works with that version of Java.

Python 2 is the millstone for SCons 3. The question is whether there
will be a 2.7.16 or whether 2.7.15 is really the last version. Also
will an organisation break ranks with PSF policy and pick up Python 2.7
and keep it going? Would that matter for SCons?

I can fully understand sticking with 3.5 at this time, but SCons
versions must be allowed to change the minimum Python version. Should
SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
then people not on Python 3.6 simply stay with SCons 3.0.X.

For me this is all about consistency: you can't demand cutting edge
SCons unless you are prepared to use cutting edge Python.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
signature.asc (application/pgp-signature, 833 B)