From 4cedb52e185f365d29e9d6d317b49b61c76ba051 Mon Sep 17 00:00:00 2001 From: Ilya Khandamirov Date: Mon, 13 Jan 2025 17:37:48 +0100 Subject: [PATCH 1/4] schedule, manager --- RELEASE_PROCESS.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 262b6da560..156b30f07b 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -28,6 +28,32 @@ the release action execution. This will lead (for most use cases) to the creation of a "Release Candidate" which can be tested and delivered to end users willing to test the new release. +### Schedule + +Minor releases are done every sprint, i.e. every two weeks. To be even more precise, +technically speaking, two releases are produced every sprint: +* Release Candidate for the current version in main +* Promotion of the previous sprint's candidate to a normal minor version + +At the end of each sprint (usually on Friday) a new release ungineer is selected, +who has to produce the releases. + +Patch releases are produced on demand, if a fix for a hefty bug must be released quickly, +and it is approved by the responsible engineer and release manager. + +### Release Manager + +Release manager (aka release coordinator, release responsible) is an engineer, whose job +is to deal with the release process. Responsibilities of the release manager include: +* Agreeing with the team, if a new release has to be produced. Sometimes, e.g. if there were +no significant contributions, or the branch is not ready, the release can be skipped +* Release branch cut-off +* Preparing a minor release candidate +* Creating a minor release +* Creating patch releases +* Approving merges into release branches and making sure they were cherry-picked from main +* Improving release process documentation (this page) + ## Release Workflow ### Diagram From cde32d1fb267f1c4b4b7adc72b3328e63789d5d5 Mon Sep 17 00:00:00 2001 From: Ilya Khandamirov Date: Mon, 13 Jan 2025 17:51:15 +0100 Subject: [PATCH 2/4] linting --- RELEASE_PROCESS.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 156b30f07b..8e72849205 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -32,10 +32,11 @@ and delivered to end users willing to test the new release. Minor releases are done every sprint, i.e. every two weeks. To be even more precise, technically speaking, two releases are produced every sprint: + * Release Candidate for the current version in main * Promotion of the previous sprint's candidate to a normal minor version -At the end of each sprint (usually on Friday) a new release ungineer is selected, +At the end of each sprint (usually on Friday) a new release ungineer is selected, who has to produce the releases. Patch releases are produced on demand, if a fix for a hefty bug must be released quickly, @@ -43,8 +44,9 @@ and it is approved by the responsible engineer and release manager. ### Release Manager -Release manager (aka release coordinator, release responsible) is an engineer, whose job +Release manager (aka release coordinator, release responsible) is an engineer, whose job is to deal with the release process. Responsibilities of the release manager include: + * Agreeing with the team, if a new release has to be produced. Sometimes, e.g. if there were no significant contributions, or the branch is not ready, the release can be skipped * Release branch cut-off @@ -113,13 +115,13 @@ At this point in time we call the minor release `0.17` cut-off. This means that: -- We no longer accept features for the development of this branch -- We no longer accept breaking changes for the development of this branch -- Any change that is not a bug fix or a documentation change must be approved by +* We no longer accept features for the development of this branch +* We no longer accept breaking changes for the development of this branch +* Any change that is not a bug fix or a documentation change must be approved by the release manager -- Any bug fix that is not deemed critical must be approved by the release +* Any bug fix that is not deemed critical must be approved by the release manager -- Any bug fix must first be merged to main and then +* Any bug fix must first be merged to main and then [`cherry-picked`](https://git-scm.com/docs/git-cherry-pick) to the release branch. From eae1d00e8e90813737215713b85e2e25a26ebc5d Mon Sep 17 00:00:00 2001 From: ikhandamirov <108289993+ikhandamirov@users.noreply.github.com> Date: Tue, 14 Jan 2025 09:08:41 +0100 Subject: [PATCH 3/4] Update RELEASE_PROCESS.md Co-authored-by: Frederic Wilhelm --- RELEASE_PROCESS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 8e72849205..ace177a806 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -34,7 +34,7 @@ Minor releases are done every sprint, i.e. every two weeks. To be even more prec technically speaking, two releases are produced every sprint: * Release Candidate for the current version in main -* Promotion of the previous sprint's candidate to a normal minor version +* Promotion of the previous sprint's candidate to an official minor version At the end of each sprint (usually on Friday) a new release ungineer is selected, who has to produce the releases. From a6a6d3707700a52541dbc624864f889ace181d21 Mon Sep 17 00:00:00 2001 From: Ilya Khandamirov Date: Tue, 14 Jan 2025 15:17:06 +0100 Subject: [PATCH 4/4] update --- RELEASE_PROCESS.md | 46 +++++++++++++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 17 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index ace177a806..c7098631aa 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -34,13 +34,19 @@ Minor releases are done every sprint, i.e. every two weeks. To be even more prec technically speaking, two releases are produced every sprint: * Release Candidate for the current version in main -* Promotion of the previous sprint's candidate to an official minor version +* Promotion of the previous sprint's candidate to an official minor version, which means there +is a grace period of one sprint. -At the end of each sprint (usually on Friday) a new release ungineer is selected, +At the end of each sprint (usually on Friday) a new release engineer is selected, who has to produce the releases. Patch releases are produced on demand, if a fix for a hefty bug must be released quickly, -and it is approved by the responsible engineer and release manager. +and it is approved by the responsible engineer and release manager. For example, a patch +is recommended for any change that is breaking backwards-compatibility or has high/critical +security relevance. + +In very rare cases it might be required to build a version outside the regular release +schedule, e.g. a special beta release. ### Release Manager @@ -49,11 +55,12 @@ is to deal with the release process. Responsibilities of the release manager inc * Agreeing with the team, if a new release has to be produced. Sometimes, e.g. if there were no significant contributions, or the branch is not ready, the release can be skipped -* Release branch cut-off -* Preparing a minor release candidate -* Creating a minor release -* Creating patch releases -* Approving merges into release branches and making sure they were cherry-picked from main +* [Release branch cut-off](#the-release-branch-creation--cutoff) +* [Preparing a minor release candidate](#preparing-a-minor-release-candidate) +* [Creating a minor release](#creating-a-minor-release) +* [Creating patch releases](#creating-a-patch-release) +* Approving merges into release branches and making sure the changes were cherry-picked from main +and fulfill "feature freeze" and "no breaking changes" requirements * Improving release process documentation (this page) ## Release Workflow @@ -92,7 +99,8 @@ gitGraph TB: ### The Release Branch Creation / Cutoff Every minor release starts with the creation of a release branch through -[`Release Branch Creation`](./.github/workflows/release-branch.yaml). +[`Release Branch Creation`](./.github/workflows/release-branch.yaml), by +executing the [Release Branch Cutoff action](https://github.com/open-component-model/ocm/actions/workflows/release-branch.yaml). The version / minor of the release is based on the content of the file [`VERSION`](./VERSION) which @@ -131,8 +139,8 @@ version as a base. ### Preparing a Minor release candidate After the cut-off, the release manager will usually prepare a release candidate. -This is done by creating a pre-release on the release branch, that goes along -with a qualifying suffix. +This is done by running [Release workflow](https://github.com/open-component-model/ocm/actions/workflows/release.yaml) +on the release branch, while specifying a qualifying suffix. Currently we only use one form of suffixed, pre-release, the `Release Candidate`: Any Release Candidate @@ -160,12 +168,12 @@ for details. ### Creating a Minor release Once a release candidate is seen as sufficiently tested, the release manager can -promote the release candidate to a full release. +promote the release candidate to a full release, by running +[Release workflow](https://github.com/open-component-model/ocm/actions/workflows/release.yaml) +on the release branch, without specifying a qualifying suffix. -By default one should always create a draft release first (as a Release -Candidate), -open it up for testing (by communicating the new release candidate as available -to stakeholders), +By default one should always create [release candidate](#preparing-a-minor-release-candidate) +first (automated announcement is posted to an internal Slack channel, so the stakeholders can start testing), and after a grace period, promote the draft release to a full release. This promotion is currently effectively a full rebuild from the release branch, @@ -176,7 +184,8 @@ After the build, instead of finishing, the release. This publishing to package registries (such as brew) is delegated to -[`publish-to-other-than-github`](./.github/workflows/publish-to-other-than-github.yaml) +[`publish-to-other-than-github`](./.github/workflows/publish-to-other-than-github.yaml), +which runs automatically as part of the release workflow. After the official release on a release branch was successful, the version is considered `burned`. This means that, even if bugs are found for that release in the future, a @@ -237,6 +246,9 @@ necessary: ### How Release Notes are managed +The release notes are auto-generated by the release action, +thus don't have to be explicitly handled by the release manager. + For every release branch there is a Github Action called [Release Drafter](./.github/workflows/release-drafter.yaml). This workflow interprets the Pull Requests merged against main and the release