Add LTS to SPEC 0 #389
Add LTS to SPEC 0 #389
Conversation
|
I think what's outlined in LTS is consistent with what scikit-learn is doing in scikit-learn/scikit-learn#30888. So I would like to ping @lesteve and @lucascolley to see if they have any thoughts or input. |
jarrodmillman
force-pushed
the
spec0+1
branch
4 times, most recently
from
3877a37 to
62246ef
Compare
| {{< 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.
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.
There was a problem hiding this comment.
Suggestions about the new text are inline.
If we were modifying other text:
- I don't understand the connection between the timeframe over which new releases support old dependency versions and the timeframe over which a given (feature) release will get bug fix releases. I think the SPEC would be more focused if it only mentions the former.
- The "Ecosystem Adoption" and "Implementation" sections are empty. Is that desirable?
- The background and motivation appears at the end, after the policy itself. Was that intentional?
- The SPEC only mentions limiting support duration as a motivation. Does it also recommend providing at least a certain amount of time - just not much more?
But if the intent is to address only LTS here, feel free to hide this comment as "off topic".
Co-authored-by: Matt Haberland <[email protected]>
| @@ -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. | |||
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
Fix #190. Fix #386. See scikit-learn/scikit-learn#30888 (comment).
Todo:
spec-0000/SPEC0_versions.py