On 01.11.2019 12:49, Julian Foad wrote:
> In the thread "Issue tracker housecleaning: SVN-1722",
> Yasuhito FUTATSUKI wrote:
>> However, it seems there is more general question, "What versions
>> do we support on Python 3?"
>>
>> It seems we don't promise to support any version of Python 3 yet.
>> So I think we can restrict version to support for Python 3,
>> comparatively safely.
>>
>> Python 3.4 had reached end of life[1]. And developers might not
>> have test environment with older Python 3.
>
> Branko Čibej wrote:
>> To be honest, I wouldn't care about any Python 3 older than 3.5. IMO it
>> took the 3.x series quite a while to mature from "wow, a new major
>> version!" to "a better scripting language". 3.5 or thereabouts was the
>> turning point.
>
> I found a nice graphic display of Python version lifetimes:
> "Python Release Cycle" <https://python-release-cycle.glitch.me/>
> linked from
> "Python 2.7 Contdown" <https://pythonclock.org/>
>
> My first thought is we don't want to waste effort supporting anything
> that isn't going to be useful, and we should be looking ahead to what
> versions it will make sense to support around the middle of next year,
> when svn 1.14 LTS is being deployed.
>
> At that point Python 3.5 will be close to its end of life, so 3.6
> looks like a reasonable minimum to require.
"End of life" and "no longer used" are two different things. I predict
we'll be seeing Python 2.7 and 3.5 installations for years to come,
despite its end-of-life.
> As Python 2.7 will be EOL before we branch svn 1.14, should we drop
> support for Python 2 right now in our development (trunk)? Not remove
> all existing support for it, not yet; that should wait until after we
> branch svn 1.14. But right now remove the promise of 2.7 support, and
> stop testing it, and stop caring about keeping compatible with it.
Going from fully supported to not at all supported in one release seems
like a bit of a stretch. On the other hand, if we want to be consistent,
we'd have to add infrastructure for keeping two separate swig-py build
trees available (e.g., for tarballs).
It's certainly easier for us to say that users who need Python 2
bindings also need Swig.
-- Brane
Received on 2019-11-01 13:59:11 CET