You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
:Author: Thomas A Caswell <tcaswell@gmail.com>, Andreas Mueller, Brian Granger, Madicken Munk, Ralf Gommers, Matt Haberland, Matthias Bussonnier <bussonniermatthias@gmail.com>, Stefan van der Walt
5
+
6
+
:Author: Thomas A Caswell <tcaswell@gmail.com>, Andreas Mueller, Brian Granger, Madicken Munk, Ralf Gommers, Matt Haberland <mhaberla@calpoly.edu>, Matthias Bussonnier <bussonniermatthias@gmail.com>, Stefan van der Walt
6
7
:Status: Draft
7
8
:Type: Informational Track
8
9
:Created: 2019-07-13
@@ -13,7 +14,7 @@ Abstract
13
14
14
15
All projects across the ecosystem should adopt a common time window
15
16
based policy for increasing the minimum version of Python and numpy
16
-
that down stream projects support. By standardizing this policy
17
+
that downstream projects support. By standardizing this policy
17
18
across community we will make it easier for down stream projects to
18
19
plan.
19
20
@@ -25,7 +26,7 @@ Detailed description
25
26
When making a new major or minor release, projects should support all
26
27
minor versions of ``CPython`` initially released in the prior 40
27
28
months from their anticipated release date and all minor version of
28
-
``numpy`` release in the prior 24 months.
29
+
``numpy`` released in the prior 24 months.
29
30
30
31
31
32
The diagram::
@@ -40,10 +41,10 @@ The diagram::
40
41
|----------------------------------------> Jul20
41
42
42
43
shows the support windows for ``CPython``. A project with a minor
43
-
release in Feb19 or Dec19 should support py36 or newer whereas a
44
+
release in Feb19 or Dec19 should support py36 and newer whereas a
44
45
project released in Jul20 should support py37 and newer.
45
46
46
-
The current CPython release cadence is 18mo so a 40 month window
47
+
The current CPython release cadence is 18 months so a 40 month window
47
48
ensures that there will always be at least two versions of ``CPython``
48
49
in the window. By padding the window by 4 months from the anticipated
49
50
``CPython`` cadence we avoid the edge cases where a project releases
@@ -57,10 +58,10 @@ on historical release dates and a project's plans, the decision to drop
57
58
support for a given version of ``CPython`` can be made very early in
58
59
the release process.
59
60
60
-
There will be some unavoidable miss match in supported version of
61
+
There will be some unavoidable mismatch in supported version of
61
62
``CPython`` between packages immediately after a version of
62
-
``CPython`` ages out. However this should not last longer that one
63
-
release cycle of each of the projects and when a given project
63
+
``CPython`` ages out. However this should not last longer than one
64
+
release cycle of each of the projects, and when a given project
64
65
does a minor or major release, it is guaranteed that there will be a
65
66
stable release of all other projects that support the set of
66
67
``CPython`` the new release will support.
@@ -69,21 +70,21 @@ stable release of all other projects that support the set of
69
70
Implementation
70
71
--------------
71
72
72
-
We suggest that all project adopt the following language into their
73
+
We suggest that all projects adopt the following language into their
73
74
development guidelines:
74
75
75
76
76
77
- support minor versions of ``CPython`` initially released
77
-
40 months prior to our planned release date.
78
-
- always support at least the 2 latest versions of ``CPython``.
78
+
40 months prior to our planned release date
79
+
- always support at least the 2 latest versions of ``CPython``
79
80
- support minor versions of ``numpy`` initially released in the 24
80
81
months prior to our planned release date or oldest that supports the
81
-
minimum python version (which ever is higher)
82
+
minimum Python version (whichever is higher)
82
83
83
-
We will bump the minimum python and numpy versions as we can on
84
-
every minor and major release, but never on a patch release
84
+
We will bump the minimum Python and numpy versions as we can on
85
+
every minor and major release, but never on a patch release.
85
86
86
-
For other dependencies adopt similar time windows of the same length
87
+
For other dependencies, adopt similar time windows of the same length
87
88
or shorter than 24 months.
88
89
89
90
@@ -100,39 +101,39 @@ Alternatives
100
101
Ad-Hoc
101
102
~~~~~~
102
103
103
-
Projects could on a every release evaluate if they want to increase
104
-
the minimum version of python supported. While this is a notionally
105
-
simple policy, it makes it hard for down-stream users to predict what
106
-
the future minimum versions will be. There is no objective threshold
104
+
Projects could on every release evaluate if they want to increase
105
+
the minimum version of Python supported. While this is a notionally
106
+
simple policy, it makes it hard for downstream users to predict what
107
+
the future minimum versions will be. As there is no objective threshold
107
108
to when the minimum version should be dropped, it is easy for these
108
109
discussions to devolve into bike shedding and acrimony.
109
110
110
111
111
-
All PSF supported versions
112
-
~~~~~~~~~~~~~~~~~~~~~~~~~~
112
+
All Python Software Foundation supported versions
113
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
113
114
114
-
This is a very clear and conservative approach. However it means that
115
+
This is a very clear and conservative approach. However, it means that
115
116
there is 4 year lag between when new language features come into the
116
117
language and when the projects are able to use them. Additionally,
117
118
for projects that have a significant component of compiled extensions
118
119
this requires building many binary artifacts for each release.
119
120
120
-
For the case of numpy, many projects carry work-arounds to bugs that
121
+
For the case of numpy, many projects carry workarounds to bugs that
121
122
are fixed in subsequent versions of numpy. Being proactive about
122
-
increasing the minimum version of numpy will allow down-stream
123
+
increasing the minimum version of numpy will allow downstream
123
124
packages to carry fewer version-specific patches.
124
125
125
126
126
127
127
128
Default version on Linux distribution
128
129
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
129
130
130
-
The policy could be support the version of python that ships by
131
+
The policy could be to support the version of Python that ships by
131
132
default in the latest Ubuntu LTS or CentOS/RHEL release. However, we
132
133
would still have to standardize across the community which
133
134
distribution we are following.
134
135
135
-
By following the versions supported by major linux distributions we
136
+
By following the versions supported by major Linux distributions, we
136
137
are giving up technical control of our projects to external
137
138
organizations that may have different motivations and concerns than we
138
139
do.
@@ -142,7 +143,7 @@ N minor versions of Python
142
143
143
144
Given the current release cadence of the CPython, the proposed time
144
145
(40 months) is roughly equivalent to "the last two" CPython minor
145
-
versions. However, if CPython changes their release cadence any rule
146
+
versions. However, if CPython changes their release cadence, any rule
146
147
based on the number of minor releases will need to be changed.
0 commit comments