-
Notifications
You must be signed in to change notification settings - Fork 431
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
Document the new release cadence and support policy #2295
Comments
We should also document what our criteria for backports is, including bug fixes and security patches, as well as evolving tests. We might want to consider limiting test evolution to the last release since that's what we're doing in practice currently. @jackfrancis @mboersma thoughts? |
I agree.
|
How about this: cherry-pick user-facing bug fixes to the latest two minor release branches, and the test improvements that have no user-facing changes to the latest release branch only (except for broken tests that need to be fixed on all release branches that are still active). |
/cc @bridgetkromhout |
/assign |
/assign |
For release 1.3, we decided to try out using a 2 months release cadence, where the milestone due date is used to indicate the next release date.
We are also going to support (backport fixes to) the last two minor releases. For example, v1.2 and v1.3. As soon as v1.4 comes out, v1.2 becomes EOL and we maintain release branches for v1.3 and v1.4.
This issue tracks documenting that process after the initial trial and error period, if we decide to stick to it. Feedback welcome.
The text was updated successfully, but these errors were encountered: