Stop supporting legacy Python versions

[ankostis]

The plan after v1.1.x is to limit compatibility of the following:.

python-2 < 2.7
python-3 < 3.3

One purpose is to demotivate the use of really old python releases.[1][2]
Another is to allow using newer syntax when programming it.

For older python-2 version, use version 1.1.x series.
[Edit:] We may have to release a legacy 1.1.11 if there is a real demand.

[1] http://carreau.github.io/posts/planning-an-early-death-for-python-2.html
[2] https://asmeurer.github.io/blog/posts/moving-away-from-python-2/

[mplanchard]

I like this idea. Should just require updating the setup metadata and test suite to make the exclusion of older versions explicit.

[redbaron4]

Python-2.6 is the default in RHEL-6 and derivatives (CentOS and SL). Though RHEL-7 has released, the transition for administrators isn't smooth and many (including me) still use RHEL-6 (which isn't that old)

[ankostis]

@redbaron4 Thanks for the tip.
That is why we would also ship 1.1.x releases.
But the general direction is this.

Is that acceptable for RHEL-6 to stick to older release-train?

[redbaron4]

@ankostis Thanks for the link. I can see the motivation for wanting to move away from Python-2.6.
I was just trying to point out that a lot of servers may still be using Python-2.6 and so it should continue to remain supported if possible. As you said, 1.1.x will probably take care of that

[mplanchard]

@redbaron4 You're absolutely right that system administration tends to move slower than the general population. In fact, I am still managing several servers on RHEL 5, believe it or not, on which we had to manually install Python 2.6 (since they came with 2.4!). That being said, even pip is moving to deprecate Python 2.6 support (throwing warnings in pip 8.0.2 and above, I believe), and I think the burden of supporting very old distributions should fall to the companies and administrators that require such support, myself included.

[astrojuanlu]

Related: "Stop Supporting Python 2.6 (For Free)" http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html

[dee-me-tree-or-love]

I would like to revive this discussion after a nice comment from @cclauss in PR #447.

"https://devguide.python.org/versions shows that Python 3.6 is not supported by the Python core team. This means no more security updates like CVE-2020-10735. Also, contributors could choose to start using Python 3.7 improvements like asyncio, data classes, and dicts are faster and are ordered by default.

Looking at Python minor version on https://pypistats.org/packages/pypiserver will show you how many downloads are happening. Supporting five versions of CPython + PyPy 3 is considered enough. It is not recommended to keep supporting unsafe versions of CPython but if that is really needed, I can try to revert those changes."

Originally posted in #447

I agree with the concern here and feel that this is becoming a more interesting item with Python evolving even further.

On the one hand, this brings stopping safety support for old versions, and on the other - many nice language built-ins and packages that can make contributions easier for the new versions. It would be very nice to approach this aspect seriously and prepare for a nice transition. I will try to put this in higher priority for the upcoming releases.

[jeffwidman]

3.7 was EOL'd end of June.

May I suggest simply having a documented policy that you only support python versions that are not EOL'd by upstream? Their policy is reasonably conservative of supporting a major version for ~4 years, and the broader python packaging ecosystem tends to drop support for EOL'd versions pretty quickly. For example pip-tools already dropped 3.7 and poetry is following suite within a few weeks.