Dropping Support for Python 2.6

[Augie Fackler]

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

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

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

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel