Skip to content

Commit

Permalink
fix review findings
Browse files Browse the repository at this point in the history
  • Loading branch information
@sbueringer
sbueringer committed Oct 12, 2022
1 parent 14ae94e commit ad474a3
Showing 1 changed file with 55 additions and 28 deletions.
83 changes: 55 additions & 28 deletions docs/developer/release-cycle.md
View file
Original file line number Diff line number Diff line change
@@ -1,33 +1,45 @@
# Release Cycle

The release cycle is the time between when we start working on a release on the `main` branch until the `.0` release (e.g. `v1.3.0`).
The release cycle is the time between when we start working on a release on the `main` branch until the `.0` release (e.g. `v1.3.0`) is released.

**Note**: For the `v1.3` and `v1.4` release cycles we assume a ~ 4 months (~ 17 weeks) release cycle. This should be revisited after the `v1.4.0` release.
**Note**: For the `v1.3` and `v1.4` releases we assume each release cycle will last approximately 4 months (~ 17 weeks).
The release cycle duration will be revisited after the `v1.4.0` release.

The release cycle can be split up into the following phases:
A release cycle can be split up into the following phases:

* Week 1-12: Active development
* Alpha releases based on the main branch can be released when necessary
* Week 13-14:
* Beta releases based on the main branch
* The beta releases are meant as a preview what the upcoming release will look like
* Providers can start adopting the new release based on the beta releases
* Breaking changes to providers have to be discussed and approved in the office hours
* Week 15-16:
* Alpha releases will be released based on the main branch only if necessary (to be determined by the release lead)
* Week 13-14: Beta
* Weekly beta releases will be released based on the main branch
* The beta releases are meant as a preview of the upcoming release
* Providers can start adopting the new release based on the beta releases
* All changes that impact providers' adoption of the new release should be announced in the provider updates section
of the office hours meeting notes and approved in the PR or issue by both approvers and key affected providers.
* Week 15-16: RC
* The release branch is created
* RC releases based on the release branch
* Weekly RC releases will be released based on the release branch
* RC releases are as close as possible to the final release but they are still undergoing further testing
* Development of the next release can technically start on the main branch, but some changes might be delayed
to ensure easier cherry-picking of other changes to the release branch.
* There is a feature freeze on the release branch
* Only bug fixes / documentation / tests fixes and additions are allowed
* Week 17:
* Only cherry-picks for documentation, bug fixes, test fixes and test additions are allowed
* Week 17: GA
* `.0` GA release is created based on the release branch
* After that:
* `.1+`: Monthly patch releases based on the release branch
* Provider releases corresponding to the CAPI minor release when they are ready
* `.1+`: Monthly patch releases will be released based on the release branch
* Cherry-picks to the release branch are allowed according to the backport policy
* Providers create releases using the new CAPI minor release when they are ready
* Development of the next release can now officially start on the main branch

Some additional notes:

* Support for new Kubernetes releases is first implemented on the main branch, then cherry-picked into
supported release branches when feasible and eventually released in the next monthly patch release(s).
* Support for new Kubernetes minor versions (for management and workload clusters) is first implemented
on the main branch, then cherry-picked into supported release branches when feasible and eventually
released in the next monthly patch release(s).
* **Note**: We usually don't have to bump Go dependencies to support new Kubernetes minor versions as it's not necessary
to run on a management cluster with the new version or create a workload cluster with the new version.
If it becomes necessary to bump dependencies to a new CR/Kubernetes minor version, the change cannot be cherry-picked
as bumping dependencies to a new minor version is a breaking change.
* New Kubernetes and Controller-Runtime (CR) minor releases are only picked up on the main branch.

The following diagram visualizes the release cycles with the v1.2, v1.3 and v1.4 releases:
Expand All @@ -37,23 +49,28 @@ The following diagram visualizes the release cycles with the v1.2, v1.3 and v1.4

# v1.3 Release Cycle timeline

**Note**: This release will be used to set up documentation, automation, etc. for the first release team which will start with
the `v1.4` release cycle.

The following table shows the preliminary dates for the `v1.3` release cycle.

| **What** | **Who** | **When** | **Week** |
|------------------------------------------------|--------------|----------------------------|----------|
| Start of Release Cycle | Release Lead | Monday 18th July 2022 | week 1 |
| 1.3.0-beta.0 released | Release Lead | Tuesday 1st November 2022 | week 13 |
| 1.3.0-beta.1 released | Release Lead | Tuesday 8th November 2022 | week 14 |
| release-1.3 branch created (**[Code Freeze]**) | Release Lead | Tuesday 15th November 2022 | week 15 |
| release-1.3 jobs created | CI Manager | Tuesday 15th November 2022 | week 15 |
| 1.3.0-rc.0 released | Release Lead | Tuesday 15th November 2022 | week 15 |
| 1.3.0-rc.1 released | Release Lead | Tuesday 22th November 2022 | week 16 |
| **1.3.0 released** | Release Lead | Tuesday 29th November 2022 | week 17 |
| **What** | **When** | **Week** |
|------------------------------------------------|----------------------------|----------|
| Start of Release Cycle | Monday 18th July 2022 | week 1 |
| 1.3.0-beta.0 released | Tuesday 1st November 2022 | week 13 |
| 1.3.0-beta.1 released | Tuesday 8th November 2022 | week 14 |
| release-1.3 branch created (**[Code Freeze]**) | Tuesday 15th November 2022 | week 15 |
| release-1.3 jobs created | Tuesday 15th November 2022 | week 15 |
| 1.3.0-rc.0 released | Tuesday 15th November 2022 | week 15 |
| 1.3.0-rc.1 released | Tuesday 22th November 2022 | week 16 |
| **1.3.0 released** | Tuesday 29th November 2022 | week 17 |

After the `.0` release monthly patch release wil be created.
After the `.0` release monthly patch release wil be created.

# v1.4 Release Cycle timeline

**Note**: The `v1.4` release will be the first release created by a dedicated release team.

The following table shows the preliminary dates for the `v1.4` release cycle.

| **What** | **Who** | **When** | **Week** |
Expand All @@ -69,3 +86,13 @@ The following table shows the preliminary dates for the `v1.4` release cycle.
| 1.4.0-rc.1 released | Release Lead | Tuesday 21th March 2023 | week 16 |
| **1.4.0 released** | Release Lead | Tuesday 28th March 2023 | week 17 |
| Organize release retrospective | Release Lead | TBC | week 17 |

## Release team

TODO: This table should be filled once the release team has been finalized in ~ this style: [Kubernetes 1.26 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.26/release-team.md) (I'm referring to the Name, Github, Slack ID pattern)

| **Role** | **Lead Name** (**GitHub / Slack ID**) | **Shadow Name(s) (GitHub / Slack ID)** |
|-------------------------------------------|---------------------------------------|----------------------------------------|
| Release Lead | | |
| Communications/Docs/Release Notes Manager | | |
| CI Signal/Bug Triage/Automation Manager | | |

0 comments on commit ad474a3

Please sign in to comment.