[Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

[Todd]

On Nov 9, 2017 20:52, "Nathaniel Smith" <njs at pobox.com> wrote:

Fortunately we can wait until we're a bit closer before we have to
make any final decision on the version numbering :-)

Right now though it would be good to start communicating to
users/downstreams about whatever our plans our though, so they can
make plans. Here's a first attempt at some text we can put in the
documentation and point people to -- any thoughts, on either the plan
or the wording?

---- DRAFT TEXT - NOT FINAL - DO NOT POST THIS TO HACKERNEWS OK? OK ----

The Python core team plans to stop supporting Python 2 in 2020. The
NumPy project has supported both Python 2 and Python 3 in parallel
since 2010, and has found that supporting Python 2 is an increasing
burden on our limited resources; thus, we plan to eventually drop
Python 2 support as well. Now that we're entering the final years of
community-supported Python 2, the NumPy project wants to clarify our
plans, with the goal of to helping our downstream ecosystem make plans
and accomplish the transition with as little disruption as possible.

Our current plan is as follows:

Until **December 31, 2018**, all NumPy releases will fully support
both Python 2 and Python 3.

Starting on **January 1, 2019**, any new feature releases will support
only Python 3.

The last Python-2-supporting release will be designated as a long-term
support (LTS) release, meaning that we will continue to merge
bug-fixes and make bug-fix releases for a longer period than usual.
Specifically, it will be supported by the community until **December
31, 2019**.

On **January 1, 2020** we will raise a toast to Python 2, and
community support for the last Python-2-supporting release will come
to an end. However, it will continue to be available on PyPI
indefinitely, and if any commercial vendors wish to extend the LTS
support past this point then we are open to letting them use the LTS
branch in the official NumPy repository to coordinate that.

If you are a NumPy user who requires ongoing Python 2 support in 2020
or later, then please contact your vendor. If you are a vendor who
wishes to continue to support NumPy on Python 2 in 2020+, please get
in touch; ideally we'd like you to get involved in maintaining the LTS
before it actually hits end-of-life, so we can make a clean handoff.

To minimize disruption, running 'pip install numpy' on Python 2 will
continue to give the last working release in perpetuity; but after
January 1, 2019 it may not contain the latest features, and after
January 1, 2020 it may not contain the latest bug fixes.

For more information on the scientific Python ecosystem's transition
to Python-3-only, see: http://www.python3statement.org/

For more information on porting your code to run on Python 3, see:
https://docs.python.org/3/howto/pyporting.html

----

Thoughts?

-n

On Thu, Nov 9, 2017 at 12:53 PM, Marten van Kerkwijk
<m.h.vankerkwijk at gmail.com> wrote:
> In astropy we had a similar discussion about version numbers, and
> decided to make 2.0 the LTS that still supports python 2.7 and 3.0 the
> first that does not.  If we're discussing jumping a major number, we
> could do the same for numpy.  (Admittedly, it made a bit more sense
> with the numbering scheme astropy had adopted anyway.) -- Marten
> _______________________________________________



Might it make sense to do this in a synchronized manner with scipy?  So
both numpy and scipy drop support for python 2 on the first release after
December 31 2018, and numpy's first python3-only release comes before (or
simultaneously with) scipy's. Then scipy can set is minimum supported numpy
version to be the first python3-only version.

That allows scipy to have a clean, obvious point where scipy supports only
the latest numpy. This will diverge later, but it seems to be a relatively
safe place to bring them back into sync.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20171112/c6e9a69d/attachment.html>