-
Notifications
You must be signed in to change notification settings - Fork 54
Add LTS to SPEC 0 #389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Add LTS to SPEC 0 #389
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,8 +32,8 @@ All versions refer to feature releases (i.e., Python 3.8.0, NumPy 1.19.0; not Py | |
|
||
Specifically, we recommend that: | ||
|
||
1. Support for Python versions be dropped **3 years** after their initial release. | ||
2. Support for core package dependencies be dropped **2 years** after their initial release. | ||
1. Support for Python versions be dropped **3 years** after the next version of Python is released. | ||
2. Support for core dependency versions be dropped **2 years** after the next version of the dependency is released. | ||
|
||
{{< admonition note >}} | ||
Core packages may or may not decide to provide bug fix releases during the full 2 year period after release. | ||
|
@@ -42,6 +42,16 @@ For instance, if a newer minimum version of a core package is needed by a projec | |
which is not backported to older versions. | ||
{{< /admonition >}} | ||
|
||
{{< admonition note >}} | ||
Certain projects (e.g., projects that have more resources) may wish to provide long-term support (LTS) of an additional year. | ||
|
||
Specifically, for projects wishing to provide LTS we recommend that: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The first sentence is that all projects should adopt a common policy. This goes against that, so I think we should acknowledge the discrepancy in some way. If we do not recommend one over the other, the first sentence might change to be "adopt one of two time-based poicies...". If we have a preference for the first but recognize the need for the other, we might say something to that effect here. |
||
|
||
1. Support for Python versions be dropped **4 years** after the next version of Python is released. | ||
2. Support for core package dependencies be dropped **3 years** after the next version of the package is released. | ||
|
||
{{< /admonition >}} | ||
|
||
### Core Project Endorsement | ||
|
||
<!-- | ||
|
@@ -84,6 +94,10 @@ The situation has since improved due to improved installations via binary wheels | |
|
||
### Support Window | ||
|
||
{{< admonition note >}} | ||
For LTS, add 1 year to the support window. | ||
{{< /admonition >}} | ||
|
||
```mermaid | ||
{{< include-raw "chart.md" >}} | ||
``` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit confused about this. This seems like one more year of support for the non-LTS recommendation but I may be missing some context ...
For Python (yearly release cadence), "3 years after the next version is released" means "4 years since the initial release".
The changes in chart.md seem to agree with this "one more year of Python support".
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. When talking about this correction of the logic, we've discussed only support for core package dependencies like NumPy. Since the time between releases is typically 6 months, we've actually discussed that we could drop support for an old version 18 months after the next version release. Since the release cadence of Python is annual, we could keep the same nominal time by making this two years after the next release and still keep the same nominal schedule.
So one option is to change these numbers to 1.5 and 2. We could make both 2 years for simplicity, but indeed, that would change the nominal support time for core dependencies.