Skip to content

Commit a11dcc8

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #7391 from sbueringer/add-release-cycle-doc
📖 doc: add release cycle doc
2 parents 9fc0cf0 + 9439cdd commit a11dcc8

File tree

2 files changed

+113
-0
lines changed

2 files changed

+113
-0
lines changed

‎docs/developer/release-cycle-overview.png

111 KB
Loading

‎docs/developer/release-cycle.md

Lines changed: 113 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,113 @@
1+
# Release Cycle
2+
3+
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.
4+
5+
**Note**: For the `v1.3` and `v1.4` releases we assume each release cycle will last approximately 4 months (~ 17 weeks).
6+
The release cycle duration will be revisited after the `v1.4.0` release.
7+
8+
A release cycle can be split up into the following phases:
9+
10+
* Week 1-12: Active development
11+
* All changes impacting providers' adoption of Cluster API should be implemented and merged in this period. Exceptions
12+
require special approval as described in the section below.
13+
* Alpha releases will be released based on the main branch only if necessary (to be determined by the release lead)
14+
* Please note that we also publish daily releases based on the main branch.
15+
* Week 13-14: Beta
16+
* Weekly beta releases will be released based on the main branch
17+
* The beta releases are meant as a preview of the upcoming release
18+
* Providers can start adopting the new release based on the beta releases
19+
* All changes that impact providers' adoption of the new release should be announced in the provider updates section
20+
of the office hours meeting notes and approved in the PR or issue by both approvers and key affected providers.
21+
* Week 15-16: RC
22+
* The release branch is created
23+
* Weekly RC releases will be released based on the release branch
24+
* RC releases are as close as possible to the final release but they are still undergoing further testing
25+
* Development of the next release can technically start on the main branch, but some changes might be delayed
26+
to ensure easier cherry-picking of other changes to the release branch.
27+
* There is a feature freeze on the release branch
28+
* Only cherry-picks for documentation, bug fixes, test fixes and test additions are allowed
29+
* Week 17: GA
30+
* `x.y.0` GA release is created based on the release branch
31+
* After that:
32+
* **Note** The following is the responsibility of the release team of the following release cycle.
33+
* `x.y.1+`: Monthly patch releases will be released based on the release branch
34+
* Cherry-picks to the release branch are allowed according to the [backport policy](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#backporting-a-patch)
35+
* Providers create releases using the new CAPI minor release when they are ready
36+
* Development of the next release can now officially start on the main branch
37+
38+
Some additional notes:
39+
40+
* Support for new Kubernetes minor versions (for management and workload clusters) is first implemented
41+
on the main branch, then cherry-picked into supported release branches when feasible and eventually
42+
released in the next monthly patch release(s).
43+
* **Note**: We usually don't have to bump Go dependencies to support new Kubernetes minor versions as it's not necessary
44+
to run on a management cluster with the new version or create a workload cluster with the new version.
45+
If it becomes necessary to bump dependencies to a new CR/Kubernetes minor version, the change cannot be cherry-picked
46+
as bumping dependencies to a new minor version is a breaking change.
47+
* New Kubernetes and Controller-Runtime (CR) minor releases are only picked up on the main branch.
48+
49+
The following diagram visualizes the release cycles with the v1.2, v1.3 and v1.4 releases:
50+
51+
<!-- The release cycle png can be opened and edited in draw.io -->
52+
![Release Cycle Overview](release-cycle-overview.png)
53+
54+
# v1.3 Release Cycle timeline
55+
56+
**Note**: This release will be used to set up documentation, automation, etc. for the first release team which will start with
57+
the `v1.4` release cycle.
58+
59+
The following table shows the preliminary dates for the `v1.3` release cycle.
60+
61+
| **What** | **When** | **Week** |
62+
|------------------------------------------------------|-------------------------------|----------|
63+
| Start of Release Cycle | Monday 18th July 2022 | week 1 |
64+
| *1.2.1 released* | Monday 15th August 2022 | week 5 |
65+
| *1.2.2 released* | Wednesday 14th September 2022 | week 9 |
66+
| *1.2.3 released* | Monday 10th October 2022 | week 13 |
67+
| *1.2.4 released* | Monday 17th October 2022 | week 14 |
68+
| 1.3.0-beta.0 released | Tuesday 1st November 2022 | week 16 |
69+
| 1.3.0-beta.1 released | Tuesday 8th November 2022 | week 17 |
70+
| *1.2.5 released* | Tuesday 8th November 2022 | week 17 |
71+
| release-1.3 branch created (**Begin [Code Freeze]**) | Tuesday 15th November 2022 | week 18 |
72+
| release-1.3 jobs created | Tuesday 15th November 2022 | week 18 |
73+
| 1.3.0-rc.0 released | Tuesday 15th November 2022 | week 18 |
74+
| 1.3.0-rc.1 released | Tuesday 22nd November 2022 | week 19 |
75+
| **1.3.0 released** | Thursday 1st December 2022 | week 20 |
76+
| *1.2.6 released* | Thursday 1st December 2022 | week 20 |
77+
78+
After the `.0` release monthly patch release will be created.
79+
80+
# v1.4 Release Cycle timeline
81+
82+
**Note**: The `v1.4` release will be the first release created by a dedicated release team.
83+
84+
The following table shows the preliminary dates for the `v1.4` release cycle.
85+
86+
| **What** | **Who** | **When** | **Week** |
87+
|------------------------------------------------------|--------------|----------------------------|----------|
88+
| Start of Release Cycle | Release Lead | Monday 5th December 2022 | week 1 |
89+
| Schedule finalized | Release Lead | Friday 9th December 2022 | week 1 |
90+
| Team finalized | Release Lead | Friday 9th December 2022 | week 1 |
91+
| *1.3.1 released* | Release Lead | Tuesday 10th January 2023 | week 6 |
92+
| *1.3.2 released* | Release Lead | Tuesday 31st January 2023 | week 9 |
93+
| 1.4.0-beta.0 released | Release Lead | Tuesday 28th February 2023 | week 13 |
94+
| *1.3.3 released* | Release Lead | Tuesday 28th February 2023 | week 13 |
95+
| 1.4.0-beta.1 released | Release Lead | Tuesday 7th March 2023 | week 14 |
96+
| release-1.4 branch created (**Begin [Code Freeze]**) | Release Lead | Tuesday 14th March 2023 | week 15 |
97+
| release-1.4 jobs created | CI Manager | Tuesday 14th March 2023 | week 15 |
98+
| 1.4.0-rc.0 released | Release Lead | Tuesday 14th March 2023 | week 15 |
99+
| 1.4.0-rc.1 released | Release Lead | Tuesday 21st March 2023 | week 16 |
100+
| **1.4.0 released** | Release Lead | Tuesday 28th March 2023 | week 17 |
101+
| *1.3.4 released* | Release Lead | Tuesday 28th March 2023 | week 17 |
102+
| Organize release retrospective | Release Lead | TBC | week 17 |
103+
104+
## Release team
105+
106+
TODO: This table should be filled once the release team has been finalized in ~ this
107+
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)
108+
109+
| **Role** | **Lead Name** (**GitHub / Slack ID**) | **Shadow Name(s) (GitHub / Slack ID)** |
110+
|-------------------------------------------|---------------------------------------|----------------------------------------|
111+
| Release Lead | | |
112+
| Communications/Docs/Release Notes Manager | | |
113+
| CI Signal/Bug Triage/Automation Manager | | |

0 commit comments

Comments
 (0)