-
Notifications
You must be signed in to change notification settings - Fork 577
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
Discuss the possibility of occasional semver-minor bumps in LTS #61
Comments
@nodejs/lts |
That sounds reasonable. We should, however, try to establish some kind of rubric for evaluating these things. For instance, changes that improve usability of testing, debugging, support, etc would have preference over changes that simply add new API calls, etc. |
I agree having the rubric will help, I also wonder if they need to be quarterly or "when appropriate" |
We should have some way of stacking them up imo, unlike the stable branch. Just so we don't do like, two in a row for LTS users who may be more on-edge. |
Dropping them into the staging branches ought to work. We'll just need to
|
+1 on getting this better defined. IMO, it is fine to stage/stack these changes, but the schedule needs to be predictable rather than the limbo that the nodejs/node#3609 is in at the moment. |
Since we have been doing occasional semver minor bumps is it safe to close this? |
Yes
|
Bringing this up due to nodejs/node#3609 and nodejs/node#4135, of which we've assessed the impact to be minimal in risk, but great in potential benefit.
Perhaps we could have occasional minor bumps on LTS lines to include these sorts of features we've carefully selected.
I suggest we do assessments quarterly to see if we should do a minor bump.
The text was updated successfully, but these errors were encountered: