Tasks for v1.12 release cycle

[pratik-mahalle]

Please see the corresponding sections of the role-handbooks for documentation of individual tasks.

Tasks

Notes:

• Weeks are only specified to give some orientation.
• The following is based on the v1.12 release cycle.

---

Week 1

• Release Lead: Finalize release schedule and team
  PR #12741
• Release Lead: Add/remove release team members
• Release Lead: Prepare main branch for development of the new release
  PR #12723
• Communications Manager: Add docs to collect release notes for users and migration notes for provider implementers
• Communications Manager: Update supported versions

---

Weeks 1–10

• Release Lead: Track - Remove previously deprecated code

---

Week 2

• Release Lead: Cut the v1.10.x & v1.11.x releases

---

Week 7

• Release Lead: Cut the v1.10.x & v1.11.x releases

---

Week 11

• Release Lead: Cut the v1.12.0-beta.0 release
• Release Lead: Cut the v1.10.x & v1.11.x releases
• Release Lead: Create a new GitHub milestone for the next release
• Communications Manager: Communicate beta to providers
• Communications Manager: Communicate upcoming code freeze to the community

---

Week 12

• KubeCon idle week

---

Week 13

• Release Lead: Cut the v1.12.0-beta.x release

---

Week 14

• Release Lead: Cut the v1.12.0-rc.0 release
• Release Lead: Set a tentative release date for the next minor release
• Release Lead: Assemble next release team
• Release Lead: Select release lead for the next release cycle
• Release Lead: Update milestone applier and GitHub Actions
• CI Manager: Setup jobs and dashboards for the release-1.12 release branch
• Communications Manager: Ensure the book for the new release is available

---

Week 15

• Release Lead: Cut the v1.12.0-rc.x release

---

Week 16

• Release Lead: Cut the v1.12.0 release
• Release Lead: Cut the v1.10.x & v1.11.x releases
• Release Lead: Organize release retrospective
• Communications Manager: Change production branch in Netlify to the new release branch
• Communications Manager: Update clusterctl links in the quickstart
• CI Manager: Post-release cleanup

---

Continuously

• Release Lead: Maintain the GitHub release milestone
• Release Lead: Bump the Go version
• Communications Manager: Communicate key dates to the community
• Communications Manager: Improve release process documentation
• Communications Manager: Maintain and improve user-facing documentation about releases, release policy and release calendar
• CI Manager: Monitor CI signal
• CI Manager: Reduce the amount of flaky tests

---

If and when necessary

• Release Lead: Track - Bump the Cluster API apiVersion
• Release Lead: Track - Bump the Kubernetes version
• Release Lead: Track Release and Improvement tasks

[sbueringer]

I updated the prepare main branch task because it's already done. Would be good if we can check what else is already completed (and link the PRs accordingly)

[pratik-mahalle]

Okay

[wendy-ha18]

Should we update release version throughout 18 weeks to correct version of this release to avoid confusion? (currently it's still version in the template).

For example, according to version support policies, I believe:

Week 6:

• [Release Lead] Cut the v1.11.2 & v1.10.7 releases

Week 9:

• [Release Lead] Cut the v1.11.3 & v1.10.8 releases

etc,.... update for the rest.
(P/S: Please help me double check the newest versions and help to correct me if I'm wrong).

[wendy-ha18]

In v1.11 Release Calendar and Tasks for v1.11 release cycle, I saw the release started with:

• v1.11.0-alpha.0 released --> Communicate alpha to providers --> v1.11.0-alpha.1 released --> v1.11.0-alpha.2 released --> v1.11.0-beta.0 released.

But look back on v1.10 we didn't have alpha.x released, we started with beta.0 released directly.

So for this release cycle, should we start with alpha.0 or beta.0 for v1.12? cc @sbueringer @mboersma

[mboersma]

So for this release cycle, should we start with alpha.0 or beta.0 for v1.12?

Good question! v1.11 was a "special" release cycle since it included the new v1beta2 API, so the maintainers decided to cut alpha releases as well.

Generally CAPI doesn't do this, we just start with the -beta.0 release. So for v1.12 we'll go back to that plan and start with v1.12.0-beta.0 as the first release.

[sbueringer]

Yup exactly. We should follow what is documented in https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/releases/release-1.12.md

It's also fine to just use v1.10.x & v1.11.x in the list above. There's no need to use the exact patch versions there

[fabriziopandini]

Hi @pratik-mahalle it seems there are some inconsistencies between the plan above and https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/releases/release-1.12.md

e.g According to the release plan, this cycle last 16 weeks, while in the plan above we are accounting for 18weeks.
Could you kindly align this issue (mostly the number of weeks) to the shorter release timeline?

[pratik-mahalle]

Hey @fabriziopandini, Thank you for pointing it out! I have updated the plan as you can see and let me know it it works or not

[fabriziopandini]

changes look good to me, thanks for the quick fix