<commit_before>==========================================================================================
NEP 28 - A standard community policy for dropping support of old Python and Numpy versions
==========================================================================================


:Author: <NAME> <<EMAIL>>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME> <<EMAIL>>, <NAME> <<EMAIL>>, <NAME>
:Status: Draft
:Type: Informational Track
:Created: 2019-07-13


Abstract
--------

All projects across the ecosystem should adopt a common time window
based policy for increasing the minimum version of Python and numpy
that downstream projects support.  By standardizing this policy
across community we will make it easier for down stream projects to
plan.



Detailed description
--------------------

When making a new major or minor release, projects should support all
minor versions of ``CPython`` initially released in the prior 42
months from their anticipated release date and all minor version of
NumPy released in the prior 24 months.


The diagram::

       Jan 16      Jan 17      Jan 18      Jan 19      Jan 20
       |           |           |           |           |
  +++++|+++++++++++|+++++++++++|+++++++++++|+++++++++++|++++++++++++
   |              |                  |               |
   py 3.5.0       py 3.6.0           py 3.7.0        py 3.8.0
  |-----------------------------------------> Feb19
            |-----------------------------------------> Dec19
                      |-----------------------------------------> Nov20

shows the support windows for ``CPython``.  A project with a minor
release in Feb19 should support py35 and newer, a project with a minor
release in Dec19 should support py36 and newer, and a project
with a minor release in Nov20 should support py37 and newer.

The current CPython release cadence is 18 months so a 42 month window
ensures that there will always be at least two versions of ``CPython``
in the window.  By padding the window by 6 months from the anticipated
``CPython`` cadence we avoid the edge cases where a project releases
the month after ``CPython`` and would effectively only support one
version of ``CPython`` that has an install base (and then the window
is 42).  This buffer also makes us resilient to minor fluctuations /
delays in the ``CPython`` release schedule.

Because the threshold for dropping a version of ``CPython`` is based
on historical release dates and a project's plans, the decision to drop
support for a given version of ``CPython`` can be made very early in
the release process.

There will be some unavoidable mismatch in supported version of
``CPython`` between packages immediately after a version of
``CPython`` ages out.  However this should not last longer than one
release cycle of each of the projects, and when a given project
does a minor or major release, it is guaranteed that there will be a
stable release of all other projects that support the set of
``CPython`` the new release will support.


Implementation
--------------

We suggest that all projects adopt the following language into their
development guidelines:


   - support minor versions of ``CPython`` initially released
     42 months prior to our planned release date
   - always support at least the 2 latest versions of ``CPython``
   - support minor versions of ``numpy`` initially released in the 24
     months prior to our planned release date or oldest that supports the
     minimum Python version (whichever is higher)

   We will bump the minimum Python and numpy versions as we can on
   every minor and major release, but never on a patch release.

For other dependencies, adopt similar time windows of the same length
or shorter than 24 months.


Backward compatibility
----------------------

No issues other than the intentional dropping of old version of
``CPython`` and dependencies.


Alternatives
------------

Ad-Hoc
~~~~~~

Projects could on every release evaluate if they want to increase
the minimum version of Python supported.  While this is a notionally
simple policy, it makes it hard for downstream users to predict what
the future minimum versions will be.  As there is no objective threshold
to when the minimum version should be dropped, it is easy for these
discussions to devolve into bike shedding and acrimony.


All Python Software Foundation supported versions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a very clear and conservative approach.  However, it means that
there is 4 year lag between when new language features come into the
language and when the projects are able to use them.  Additionally,
for projects that have a significant component of compiled extensions
this requires building many binary artifacts for each release.

For the case of numpy, many projects carry workarounds to bugs that
are fixed in subsequent versions of numpy.  Being proactive about
increasing the minimum version of numpy will allow downstream
packages to carry fewer version-specific patches.



Default version on Linux distribution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The policy could be to support the version of Python that ships by
default in the latest Ubuntu LTS or CentOS/RHEL release.  However, we
would still have to standardize across the community which
distribution we are following.

By following the versions supported by major Linux distributions, we
are giving up technical control of our projects to external
organizations that may have different motivations and concerns than we
do.

N minor versions of Python
~~~~~~~~~~~~~~~~~~~~~~~~~~

Given the current release cadence of the CPython, the proposed time
(42 months) is roughly equivalent to "the last two" CPython minor
versions.  However, if CPython changes their release cadence, any rule
based on the number of minor releases will need to be changed.


Time window on the X.Y.1 CPython release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can achieve the same name effect by making the window longer which is
easier to explain.


Discussion
----------


References and Footnotes
------------------------


Copyright
---------

This document has been placed in the public domain.<commit_msg>DOC: wording and spelling tweaks<commit_after>==========================================================================================
NEP 28 - A standard community policy for dropping support of old Python and NumPy versions
==========================================================================================


:Author: <NAME> <<EMAIL>>, <NAME>, <NAME>, <NAME>, <NAME>, <NAME> <<EMAIL>>, <NAME> <<EMAIL>>, <NAME>
:Status: Draft
:Type: Informational Track
:Created: 2019-07-13


Abstract
--------

All projects across the ecosystem should adopt a common time window
based policy for increasing the minimum version of Python and NumPy
that downstream projects support.  By standardizing this policy
across community we will make it easier for down stream projects to
plan.



Detailed description
--------------------

When making a new major or minor release, projects should support all
minor versions of ``CPython`` initially released in the prior 42
months from their anticipated release date and all minor version of
NumPy released in the prior 24 months.


The diagram::

       Jan 16      Jan 17      Jan 18      Jan 19      Jan 20
       |           |           |           |           |
  +++++|+++++++++++|+++++++++++|+++++++++++|+++++++++++|++++++++++++
   |              |                  |               |
   py 3.5.0       py 3.6.0           py 3.7.0        py 3.8.0
  |-----------------------------------------> Feb19
            |-----------------------------------------> Dec19
                      |-----------------------------------------> Nov20

shows the support windows for ``CPython``.  A project with a minor
release in Feb19 should support py35 and newer, a project with a minor
release in Dec19 should support py36 and newer, and a project
with a minor release in Nov20 should support py37 and newer.

The current CPython release cadence is 18 months so a 42 month window
ensures that there will always be at least two versions of ``CPython``
in the window.  By padding the window by 6 months from the anticipated
``CPython`` cadence we avoid the edge cases where a project releases
the month after ``CPython`` and would effectively only support one
version of ``CPython`` that has an install base (and then the window
is 42).  This buffer also makes us resilient to minor fluctuations /
delays in the ``CPython`` release schedule.

Because the threshold for dropping a version of ``CPython`` is based
on historical release dates and a project's plans, the decision to drop
support for a given version of ``CPython`` can be made very early in
the release process.

There will be some unavoidable mismatch in supported version of
``CPython`` between packages immediately after a version of
``CPython`` ages out.  However this should not last longer than one
release cycle of each of the projects, and when a given project
does a minor or major release, it is guaranteed that there will be a
stable release of all other projects that support the set of
``CPython`` the new release will support.


Implementation
--------------

We suggest that all projects adopt the following language into their
development guidelines:


   - support minor versions of ``CPython`` initially released
     42 months prior to our planned release date
   - always support at least the 2 latest versions of ``CPython``
   - support minor versions of ``numpy`` initially released in the 24
     months prior to our planned release date or oldest that supports the
     minimum Python version (whichever is higher)

   The minimum supported version of ``CPython`` will be set to
   ``python_requires`` in ``setup`` and all supported versions of
   Python will be in the test matrix and have binary artifacts built
   for releases.

   We will bump the minimum Python and NumPy versions as we can on
   every minor and major release, but never on a patch release.

For other dependencies, adopt similar time windows 24 months shorter.


Backward compatibility
----------------------

No issues other than the intentional dropping of old version of
``CPython`` and dependencies.


Alternatives
------------

Ad-Hoc
~~~~~~

Projects could on every release evaluate if they want to increase
the minimum version of Python supported.  While this is a notionally
simple policy, it makes it hard for downstream users to predict what
the future minimum versions will be.  As there is no objective threshold
to when the minimum version should be dropped, it is easy for these
discussions to devolve into bike shedding and acrimony.


All Python Software Foundation supported versions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a very clear and conservative approach.  However, it means that
there is 4 year lag between when new language features come into the
language and when the projects are able to use them.  Additionally,
for projects that have a significant component of compiled extensions
this requires building many binary artifacts for each release.

For the case of NumPy, many projects carry workarounds to bugs that
are fixed in subsequent versions of NumPy.  Being proactive about
increasing the minimum version of NumPy will allow downstream
packages to carry fewer version-specific patches.



Default version on Linux distribution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The policy could be support the version of Python that ships by
default in the latest Ubuntu LTS or CentOS/RHEL release.  However, we
would still have to standardize across the community which
distribution we are following.

By following the versions supported by major Linux distributions, we
are giving up technical control of our projects to external
organizations that may have different motivations and concerns than we
do.

N minor versions of Python
~~~~~~~~~~~~~~~~~~~~~~~~~~

Given the current release cadence of the CPython, the proposed time
(42 months) is roughly equivalent to "the last two" CPython minor
versions.  However, if CPython changes their release cadence, any rule
based on the number of minor releases will need to be changed.


Time window on the X.Y.1 CPython release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As the first bug fix release is typically a few months after the
initial release, you can achieve the same name effect by making the
window longer which is easier to explain.


Discussion
----------


References and Footnotes
------------------------


Copyright
---------

This document has been placed in the public domain.
{'fraction_non_alphanumeric': 0.13549814331990204, 'fraction_numerical': 0.011377103579047167, 'mean_word_length': 3.309839972761321, 'pattern_counts': {'":': 0, '<': 31, '<?xml version=': 0, '>': 37, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 10, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6069470', 'n_tokens_mistral': 3025, 'n_tokens_neox': 2755, 'n_words': 1721}