Skip to content
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

Closed
CecileRobertMichon opened this issue May 12, 2022 · 6 comments · Fixed by #2628
Closed

Document the new release cadence and support policy #2295

CecileRobertMichon opened this issue May 12, 2022 · 6 comments · Fixed by #2628
Assignees
Labels
kind/documentation Categorizes issue or PR as related to documentation.
Milestone

Comments

@CecileRobertMichon
Copy link
Contributor

  1. What release cadence should we adopt going forward? CAPI is discussing formalizing a release cadence. Current proposal from discussion is to not follow CAPI release cadence but to define our own CAPZ release cadence for minor (feature) releases of either 1 minor release every month or every 2 months
  2. How many minor release branches should we “support” at any given time? For example, if we release features every 2 months, we could keep backporting bug fixes to the last 2 releases at any given time, meaning each minor release would be “in support” for ~4 months.

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.

@CecileRobertMichon CecileRobertMichon added the kind/documentation Categorizes issue or PR as related to documentation. label May 12, 2022
@CecileRobertMichon CecileRobertMichon added this to the v1.4 milestone May 12, 2022
@CecileRobertMichon
Copy link
Contributor Author

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?

@jackfrancis
Copy link
Contributor

I agree.

  1. We should probably as a rule "require" test changes/fixes/evolutions to be cherry-picked into the last release branch, so that we minimize friction for any critical test fix
  2. Officially document "test maintenance" as an allowable changeset for a cherry-pick (in addition to bug fixes and security patches)

@CecileRobertMichon
Copy link
Contributor Author

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).

@CecileRobertMichon
Copy link
Contributor Author

/cc @bridgetkromhout

@jackfrancis
Copy link
Contributor

/assign

@mboersma
Copy link
Contributor

/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/documentation Categorizes issue or PR as related to documentation.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants