-
Notifications
You must be signed in to change notification settings - Fork 44
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
LTS release strategy RFC #23
Conversation
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.
Thanks for putting this together Dave. Very helpful to see it all on paper, so to speak.
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.
Generally looks good to me. A few thoughts though.
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.
Not perfect but good enough. I think there are a few lines which could be interpreted slightly differently, but overall this is a good start.
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.
LGTM. Just a few minor comments.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
|
||
## LTS release duration | ||
|
||
Once a *subsequent* LTS release is designated, users can expect 3rd digit patch releases to address critical bugs on the *prior* LTS release for approximately 9 more months. The maintainers will determine which fixes should to be backported to the latest LTS release, versus which fixes need to be further backported to the prior LTS release. 3rd digit patch releases should be expected less frequently for prior LTS releases, since only critical fixes will be published. The overlap period is intended to provide users a time window to upgrade their nodes, and any channel capabilities (if required). |
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.
Somehow, 9 month is a little shorter as "long term".
Typically it's several years for most existing software from https://en.wikipedia.org/wiki/Long-term_support.
I think it should make sense to extend it to 12 month at least.
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.
9 months is the time for which two LTS releases will live simultaneously. This is saying once 2.x is marked as LTS we will continue delivering bug fixes to 1.4 for 9 months. It doesn't speak to length of time 2.x will actually be LTS for, that could be several years, and then once we deliver a new LTS after 2.x, then 2.x will continue to receive bug fixes for 9 months, while living simultaneously with the LTS after 2.x
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.
Make sense!
Besides, it would be better describe the interval between two LTS versions, too.
No concerns raised during Final Comment Period, let's go ahead and merge. |
the prior LTS release support for 9 months when the new LTS is announced is a short time frame compared to other enterprise products. If you have implemented production Fabric frameworks in a network on a prior LTS updating in 9 months may be a real challenge, depending on the quality of the migration tools provided. Also, regulations may require running only LTS versions which can be a problem. Many other enterprise products provide a 12 month prior LTS support window. |
Signed-off-by: David Enyeart enyeart@us.ibm.com