Document the release process for v1beta1

[killianmuldoon]

User Story

As a developer I would like to understand all the actions that are taken in a major version change for Cluster API.

Detailed Description

While we're moving from v1alpha4 to v1beta1 we should do our best to document all the work items that need to be done, and the decisions that need to be made in making such a release. It might be a good idea to use a specific label (area/release is there and looks underused) to mark all of the work items. This can then be consolidated into a fuller release guide down the line.

The current release guide at https://github.com/kubernetes-sigs/cluster-api/blob/master/docs/developer/releasing.md is only really concerned with Github and docker image releases. There are a number of other pieces of work documented in the book https://cluster-api.sigs.k8s.io/contributing?search=release

It would be great to end up with a single higher-level how to release a cluster API release doc after the v1beta1 process is complete.

/kind documentation
/kind feature

[vincepri]

/milestone v1.0

[fabriziopandini]

@killianmuldoon an additional step to keep into account for this is updating the milestone applier plugin, prior art kubernetes/test-infra#24102

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sbueringer]

We've created issue to track tasks for CAPI v1.1/v1.2 and Kubernetes v1.24:

• Tasks for Kubernetes v1.24 #5968
• Tasks for release v1.1 branch and starting v1.2 cycle #5967

There are probably a few things missing which we'll add over time. I also think these issues will evolve from one release to another as our processes/code changes.

I'm not sure if we should - in addition to the tracking/umbrella issues - document the entire issues in the book.

I assume it will be hard to keep up-to-date and will always be redundant information to the issues, as we will need the issues anyway.

P.S. If we have certain "constant" sub-tasks for which we think it's worth adding documentation to the book, I'm not against it (e.g. like we did for the steps to publish the actual release).

@killianmuldoon WDYT?

[killianmuldoon]

P.S. If we have certain "constant" sub-tasks for which we think it's worth adding documentation to the book, I'm not against it (e.g. like we did for the steps to publish the actual release).

That's what I was thinking with this issue orignally, but I didn't get around to it. I'll work on getting something into the book for just after this release cycle.

[sbueringer]

P.S. If we have certain "constant" sub-tasks for which we think it's worth adding documentation to the book, I'm not against it (e.g. like we did for the steps to publish the actual release).

That's what I was thinking with this issue orignally, but I didn't get around to it. I'll work on getting something into the book for just after this release cycle.

I'll try to keep the umbrella issues and the issues linked there up-to-date and try to include relevant details.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[fabriziopandini]

@killianmuldoon can we close this given that we have a ~complete task list in #5281

[killianmuldoon]

Yeah, I think this can be closed.

/close

[k8s-ci-robot]

@killianmuldoon: Closing this issue.

In response to this:

Yeah, I think this can be closed.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.