draft for LTS releases #279
Conversation
|
Maintainers, As you review this RFC please queue up issues to be created using the following commands: Issues(none) |
joe-kimmel-vmw
force-pushed
the
lts-releases
branch
3 times, most recently
from
8be8092
to
ad4a2e1
Compare
text/0000-lts-releases.md
Outdated
| # How it Works | ||
| [how-it-works]: #how-it-works | ||
|
|
||
| Lifecycle will maintain a publicly viewable table of LTS versions with anticipated sunset dates for support. |
There was a problem hiding this comment.
We currently have this table: https://github.com/buildpacks/lifecycle#supported-apis
Which should probably be updated to not even mention lifecycle versions that are more than a year old (unrelated to this RFC, I find it hard to imagine anyone cares about the older versions). It could be modified to (**) the ones that are LTS versions
There was a problem hiding this comment.
the argument(s) I can think of for keeping a long historical tail:
- shows the project has been around for a while
- gives you something to point at if/when somebody is using an ancient version ("that version has been out of support for 18 months!" is more convincing with a link)
- helps someone see patterns in support/sunset windows
though i agree generally people are only going to care about the top couple rows of any such table
|
|
||
| Lifecycle will maintain a publicly viewable table of LTS versions with anticipated sunset dates for support. | ||
| Not all Lifecycle releases will need to be LTS, but 3-5 each year probably will be marked as LTS. Maintainers will be responsible for marking releases as LTS. | ||
| Some additional release automation will be built to support patching and releasing LTS releases. |
There was a problem hiding this comment.
Potentially:
- Automation around release notes (having better / more standardized PR & issue templates could help here)
- Some system where tagging a PR as applicable to an LTS release creates new PRs against the LTS tags
It's probably not necessary to put this in the RFC, I'm just thinking out loud here
Signed-off-by: Joe Kimmel <[email protected]>
joe-kimmel-vmw
force-pushed
the
lts-releases
branch
from
ad4a2e1
to
15a72a2
Compare
Signed-off-by: Joe Kimmel <[email protected]>
natalieparellano
added
team/implementation
type/rfc
status/needs-steward
scope/team
|
I'd be happy to steward this one |
upgrade to the latest but specify API version Signed-off-by: Joe Kimmel <[email protected]>
|
@jabrown85 any thoughts on this one? |
There was a problem hiding this comment.
I am not convinced of this RFC yet. I would like the lifecycle maintainers to pitch in here and consider the maintanance costs and also appropriate recommendations for the end user. Given lifecycle's strong backwards compatibility guarantees, I'm not sure how much it's worth porting patch releases to older lifecycle versions unless we decide to introduce deprecations in a newer version. Even there I don't believe we have ever deprecated any buildpack or platform api versions that are less than an year old.
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| Lifecycle to define approximately 4 releases per year as LTS. |
There was a problem hiding this comment.
This seems fairly high. I don't think we actually do enough minor releases an year that picking 4 would help (looking back at the last couple of years, we seem to make ~2 minor releases an year). The max number of lifecycle minor releases we have ever done in an year is 5 (during the year the project started). This would roughly result in every lifecycle minor being an LTS. I would be more comfortable if we reduce this cadence.
I also am not sure how much benefit this provides us given lifecycle is supposed to provide strong backwards compatibility guarantees.
There was a problem hiding this comment.
If the argument were instead made for one lifecycle release every 1 year (or possibly every 2 years) being marked as LTS, this would make more sense to me.
Looking at other large projects that provide LTS releases, they are usually in the order of years instead of months.
There was a problem hiding this comment.
I agree with Sam. I think 1-2 LTS releases a year seem like plenty.
There was a problem hiding this comment.
Thanks - that makes sense
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
There was a problem hiding this comment.
I would like this section to be more fleshed out and list scenarios where we would recommend patches of older lifecycle versions rather than the latest.
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| Lifecycle to define approximately 4 releases per year as LTS. |
There was a problem hiding this comment.
I agree with Sam. I think 1-2 LTS releases a year seem like plenty.
|
|
||
| - Why should we do this? Some organizations that bundle lifecycle into other products are sufficiently risk-averse to be opposed to upgrading to the latest version, but still desire critical CVE patches. This LTS patch-backporting strategy allows us to support these slower moving vendors with minimal effort. | ||
| - What use cases does it support? See above. | ||
| - What is the expected outcome? Lifecycle will have to maintain a trailing list of supported LTS versions with approximate sunset dates for each. Then for certain CVEs there will be some additional "release engineering" effort to ease backporting and then releasing patch versions. |
There was a problem hiding this comment.
Does having LTS give lifecycle maintainers any advantages?
There was a problem hiding this comment.
Not that I'm aware of
| [alternatives]: #alternatives | ||
|
|
||
| - What other designs have been considered? | ||
| - Just upgrade to the latest: Our current approach encourages all users to upgrade to the latest binary but allows them to specify the version of the API to use. This works pretty well until some large enterprise partners don't want to do it because they're so risk averse that they want the reassurance that the changeset is the minimal one necessary to addrress the CVEs. |
There was a problem hiding this comment.
With the introduction of LTS - do we see a future where lifecycle stops taking in Platform API all together?
There was a problem hiding this comment.
seems unlikely, doesn't it?
|
Thanks all for the feedback. I think we are closing this in favor of a proposal with substantially less commitment, and hopefully also a better motivation / addressing some of the comments above: #281 |
No description provided.