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 <futat...@yf.bsdclub.org>/<futat...@poem.co.jp>
