From 4cedb52e185f365d29e9d6d317b49b61c76ba051 Mon Sep 17 00:00:00 2001 From: Ilya Khandamirov Date: Mon, 13 Jan 2025 17:37:48 +0100 Subject: [PATCH] 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