Re: What versions of Python 3 do we support?

On 2019/11/01 21:59, Branko Čibej wrote:
> 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.

I'm sure my office continue to use Python 2.7 at least 4 years
on CentOS 7, if my office will still exist.

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

For users which already uses swig Python bindings in their
application and waiting for our swig binding support Python 3, dual
support of Python 2 and Python 3 can make a grace period to improve
their application for Python 3. So it is worse to do so, I think.

My primary purpose to join to develop swig-py3 branch was to see that
ViewVC officially supports Python 3.

(I myself already make ViewVC work with Python 3 experimentally
by using Cython, though. I long for someone to develop the script
to generate Cython header files from C API inclue files :))

> It's certainly easier for us to say that users who need Python 2
> bindings also need Swig.

... or add targets in Makefile to archive/extract pre-generated code
by SWIG, and bundle their archive as tarball in tarball, etc., if
the problem is shipping method only (but I don't estimate difficulty).

Cheers,

-- 
Yasuhito FUTATSUKI <futatuki_at_yf.bsdclub.org>/<futatuki_at_poem.co.jp>