Dropping Support for Python 2.6
raf at durin42.com
Fri Apr 28 11:00:43 EDT 2017
On Thu, Apr 27, 2017 at 12:23:18PM -0700, Gregory Szorc wrote:
> I think the time has come to make a decision about dropping support for
> Python 2.6.
> In , 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 , Augie seemed to indicate that he supports 4.2 or 4.3 being the last
> release that supports Python 2.6.
Strongly in favor of dropping 2.6 as soon as possible. We're breaking
it several times a cycle at this point and it's well past its sell-by
> 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).
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
More information about the Mercurial-devel