Dropping Support for Python 2.6

[Gregory Szorc]

I think the time has come to make a decision about dropping support for
Python 2.6.

In [1], we already decided that supporting 2.6 on Windows made no sense.
While I don't think we ever wrote a patch, support for 2.6 on Windows is
effectively gone.

Also in that thread, Facebook said they will stop caring about Python 2.6
no later than 2017-04-30. Facebook runs some internal CI that helps flush
out upstream bugs. And once they drop 2.6 support on their end, I imagine
it will be more difficult for them to contribute certain things to core
because they require 2.7. I'd like to not inconvenience one of our largest
source of contributions.

In [2], Augie seemed to indicate that he supports 4.2 or 4.3 being the last
release that supports Python 2.6.

At this point in time, Python 2.6 is a constant thorn in our side to
support. It is hampering efforts to modernize the code. This is making the
Python 3 port more difficult than it could be. There are bugs and
workarounds for 2.6 that are just plain ugly. Furthermore, Python 2.6 isn't
a secure execution platform. It doesn't support modern TLS versions and
features. Upstream CPython support has been dead since 2013. Only long term
support distros like RedHat 6 continue to run and support Python 2.6.

I'd like to formally propose making Mercurial 4.2 (the release scheduled
for May 1) the last release that supports Python 2.6.

I anticipate that dropping 2.6 support will only inconvenience users on
certain, legacy Linux distributions and other *NIX operating systems in a
similar boat. Of these, I'm willing to wager that we really only care about
RHEL 6 and variants (like CentOS 6). If these users will be significantly
inconvenienced by lack of Python 2.6 support, I propose we make it easy to
produce a self-contained Mercurial RPM containing a bundled Python 2.7.
e.g. `make docker-centos6`. The Python within would be installed to e.g.
/usr/lib/mercurial and wouldn't interfere with system operation: only
shebangs in `hg` and other Mercurial-related executables would reference
it. If the *capability* of producing those RPMs from a source distribution
is not enough, we can consider hosting those RPMs on www.mercurial-scm.org
for direct download (read: we wouldn't operate a full RPM repository with
metadata, just raw files).

[1]
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/094837.html
[2]
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/097074.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170427/07501d66/attachment.html>