Add a PLEP on release schedule #43
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
namurphy
commented
Jan 24, 2023
Comment on lines
+62
to
+67
| To implement this PLEP, it will be necessary to implement | ||
| infrastructure for performing backports for LTS releases. For example, | ||
| when a pull request for Astropy is labeled as appropriate for a | ||
| backport, then a GitHub tool will automatically create a pull request | ||
| to the appropriate branches. This infrastructure will reduce the | ||
| effort needed to perform backports and minor releases. |
There was a problem hiding this comment.
We should probably delay a decision on an LTS policy until we have better infrastructure in place to do backports. I want to look into how Astropy and other packages have backports set up too.
|
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
|
There has just been an Astropy Proposal for Enhancement that would end Astropy's practice of doing LTS releases. Essentially, Astropy has achieved enough stability that LTS releases aren't really that beneficial. Plus, LTS releases are not standard practice in the scientific pythoniverse. So, unless we have a strong use case and sufficient resources, it seems like we should learn from Astropy and not do LTS releases. |
namurphy
commented
May 24, 2023
Comment on lines
+1
to
+3
| ========================================================= | ||
| PLEP-0009 – Release schedule and long-term support policy | ||
| ========================================================= |
There was a problem hiding this comment.
Suggested change
| ========================================================= | |
| PLEP-0009 – Release schedule and long-term support policy | |
| ========================================================= | |
| ============================ | |
| PLEP-0009 – Release schedule | |
| ============================ |
namurphy
commented
May 24, 2023
Comment on lines
+27
to
+28
| This PLEP describes the nominal release schedule and long-term support | ||
| (LTS) policy for PlasmaPy. |
There was a problem hiding this comment.
Suggested change
| This PLEP describes the nominal release schedule and long-term support | |
| (LTS) policy for PlasmaPy. | |
| This PLEP describes the nominal release schedule for PlasmaPy. |
namurphy
commented
May 24, 2023
Comment on lines
+51
to
+57
| Long-term support policy | ||
| ------------------------ | ||
|
|
||
| If there is sufficient funding for the development and maintenance of | ||
| PlasmaPy, then the first release in even-numbered years will be an LTS | ||
| release that will be maintained with bugfixes and documentation | ||
| improvements for two years. |
There was a problem hiding this comment.
Suggested change
| Long-term support policy | |
| ------------------------ | |
| If there is sufficient funding for the development and maintenance of | |
| PlasmaPy, then the first release in even-numbered years will be an LTS | |
| release that will be maintained with bugfixes and documentation | |
| improvements for two years. | |
| No designated long-term support releases | |
| ---------------------------------------- | |
| PlasmaPy will not designate any releases as long-term support (LTS) | |
| releases. Packages that depend on PlasmaPy should perform cron tests | |
| using the `main` branch of PlasmaPy's repository. |
namurphy
commented
May 24, 2023
| users, and more difficulty keeping track of citations. | ||
|
|
||
| A release cadence of four months balances these tradeoffs. | ||
|
|
There was a problem hiding this comment.
Need to add a section that addresses the alternative of having LTS releases.
namurphy
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is to create a PLEP that defines a regular release schedule (January, May, and September of each year) and an LTS policy.
This isn't urgent at all, so there's no need to review it yet. In particular, we don't have a strong need for LTS releases yet, so it'd probably be best to delay thinking about this for a while.