summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorThomas A Caswell <tcaswell@gmail.com>2019-08-14 12:24:35 -0400
committerThomas A Caswell <tcaswell@gmail.com>2019-08-14 12:24:35 -0400
commitfc5741025ea6f9e437f1d896d98b630aec107469 (patch)
tree37e8e0b23ca3802603ca81cdda15f7abd5c4b56b /doc
parent7d61653e79ff6779b720dc067945276bdd1921e5 (diff)
downloadnumpy-fc5741025ea6f9e437f1d896d98b630aec107469.tar.gz
DOC: add another paragraph about why N-releases is problematic
Diffstat (limited to 'doc')
-rw-r--r--doc/neps/nep-0029-deprecation_policy.rst17
1 files changed, 12 insertions, 5 deletions
diff --git a/doc/neps/nep-0029-deprecation_policy.rst b/doc/neps/nep-0029-deprecation_policy.rst
index fcc28e7c6..8224e1139 100644
--- a/doc/neps/nep-0029-deprecation_policy.rst
+++ b/doc/neps/nep-0029-deprecation_policy.rst
@@ -208,11 +208,18 @@ do.
N minor versions of Python
~~~~~~~~~~~~~~~~~~~~~~~~~~
-Given the current release cadence of the Python, the proposed time
-(42 months) is roughly equivalent to "the last two" Python minor
-versions. However, if Python changes their release cadence substantially, any rule
-based solely on the number of minor releases may need to be changed to remain sensible.
-
+Given the current release cadence of the Python, the proposed time (42
+months) is roughly equivalent to "the last two" Python minor versions.
+However, if Python changes their release cadence substantially, any
+rule based solely on the number of minor releases may need to be
+changed to remain sensible.
+
+A more fundamental problem with a policy based on number of Python
+releases is that it is hard to predict when support for a given minor
+version of Python will be dropped as that requires correctly
+predicting the release schedule of Python for the next 3-4 years. A
+time-based rule is only depends on things that have already happened
+and the length of the support window.
Time window on the X.Y.1 Python release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~