Add release schedule and bugfix policy #3948
Conversation
|
Let's float w/ others. |
| certain minor releases as LTS (long term support) releases. Whenever a bug | ||
| warrants a patch release with a fix for the bug, it will be backported and | ||
| released as a new patch release for each LTS minor version. Our current LTS | ||
| releases are: |
There was a problem hiding this comment.
Do we expect to have multiple? I think in general the convention is to have one LTS release that expires when the next one rolls around?
There was a problem hiding this comment.
I was thinking we would have two for around a month of overlap when one expires.
There was a problem hiding this comment.
Do you think it'd be worthwhile calling that out explicitly here?
There was a problem hiding this comment.
Perhaps a better policy is every three months. Then we have two LTS releases at any one time (at least starting three months from now).
| * `1.8.x` - LTS release until February 2022. | ||
|
|
||
| Each LTS release will continue to receive backported fixes for at least half a | ||
| year. If you wish to use a fixed minor release in your project, we recommend |
There was a problem hiding this comment.
I'd like to see actual motivation here — no-one (I don't think) wants to use "a fixed minor release" — we should give example motivations for why you may want to stay on an LTS. If we can't come up with any, that's a good indication that we shouldn't have LTS releases in the first place.
There was a problem hiding this comment.
Well, I see people use a fixed version every so often. Usually it's because there's some change they wanted to avoid, e.g. some people used a fixed version to avoid coop. Another reason could be wanting to test the software on new minor releases before upgrading to ensure there are no regressions.
Anyway, we should also consider from the other direction. If we want to not have LTS releases, what alternative backport policy do we go for instead? Making releases with the fix for #3929 was quite a lot of work, and it would have been less work with an LTS policy. The main other alternative that avoids this is just not backporting at all — is that the policy we want?
There was a problem hiding this comment.
Honestly, I would say that LTS should be for major versions, not minor versions. If you decide to pin an old minor version, I don't think you should expect backports. Instead, we should work to roll forwards with what's blocking people from upgrading. Otherwise, minor releases start to smell like major releases, which I don't think is a game we want to get into.
But if we want to have LTS minor releases, then I think we should stipulate exactly when they're warranted. "So that upgrades are manual" is semi-fair, though (at least to me) is a smell of something being wrong — in general, upgrading within a major version should always be fine, otherwise something is wrong.
There was a problem hiding this comment.
It is uncommon, but I do know for a fact that there are users that want to stick on 1.x lines and only move forward explicitly but pull in patches at a faster rate.
The issue is, while there are no breaking changes in minor releases, there can be large internal changes that increase the risk of subtle behavior changes (or bugs). E.g. an application incorrectly depended on behavior that was not specified.. So, upgrades are punted to fixed points in time. This is an internal process decision Those users would also like to get critical bug fixes.
You could argue that we just shouldn't support that use case, but I would lean towards some sort of middle ground and back porting critical fixes.
|
I updated the text and mirrored it to the other README. |
readme: add release schedule and bugfix policy (tokio-rs#3948)
This PR contains describes the release schedule and proposes a new policy for backporting bugfixes.