From 3575f11e4d94e4349e139ff907d94adce1de413d Mon Sep 17 00:00:00 2001 From: jack1142 <6032823+jack1142@users.noreply.github.com> Date: Fri, 9 Jul 2021 03:54:57 +0200 Subject: [PATCH] More work on describing different types of releases --- source/core-devs/release-process.rst | 136 ++++++++++++++++++++++++--- 1 file changed, 124 insertions(+), 12 deletions(-) diff --git a/source/core-devs/release-process.rst b/source/core-devs/release-process.rst index 3f47865..32d90f9 100644 --- a/source/core-devs/release-process.rst +++ b/source/core-devs/release-process.rst @@ -4,25 +4,78 @@ Release process Red's release process involves a bit of work. This document attempts to collect, in one place, all the steps needed to make a release of Red. +Types of releases +----------------- + +- Breaking release (``3.x+1.0``) + + Release with breaking changes, done from ``V3/develop``. + +- Standard release (``3.x.y+1``) + + Release without breaking changes that may contain both features and bugfixes. + + This is done from ``V3/develop`` or ``3.x`` branch + if a breaking release is currently in development. + +- Maintenance release (``3.x.y+1``) + + Release without breaking changes that only contains cherry-picked enhancements and bugfixes. + + As opposed to standard release, it is done from a short-lived release branch + using the tag of a previous version as a base. + +- Hotfix release (``3.x.y+1``) + + Release that is meant to quickly patch one of the currently supported releases + (usually it is just the latest). + + This is done from a short-lived release branch using the tag of a previous version as a base, + or from ``V3/develop``/``3.x`` if it doesn't contain any meaningful code changes yet. + + Making a release ---------------- #. Ensure there are no release blockers. - Look at the milestone for the next release and check if there are any Release Blockers - (labelled as "Release Blocker" on the issue tracker) that need to be handled before the release. + .. tab:: Hotfix release + + You can *generally* skip this. Might still be worth checking + in case there is some blocker related to release workflow that could potentially affect you. + + .. tab:: Everything else + + Look at the milestone for the next release and check if there are any Release Blockers + (labelled as "Release Blocker" on the issue tracker) that need to be handled before the release. #. Check state of all open pull requests for this milestone. - Decide which should be kept for the release, cooperate with another org member(s) on this. - Move any pull requests not targeted for release to a new milestone with name of the release - that should come after current one. + .. tab:: Hotfix release + + This is a hotfix release, you should focus on getting the critical fix out, + everything else should not be important. + + .. tab:: Everything else + + Decide which should be kept for the release, cooperate with another org member(s) on this. + Move any pull requests not targeted for release to a new milestone with name of the release + that should come after current one. #. Review changelog PR. - Add (or ask PR author to add) any missing entries based on the release's milestone. - Verify that contributors list is complete and in alphabetical order. - Merge the PR once it's ready. + .. tab:: Hotfix release + + Hotfix releases need to contain a changelog. + + It can be limited to a short description of what the hotfix release fixes, for example see: + `Red 3.4.12 changelog `__ + + .. tab:: Everything else + + Add (or ask PR author to add) any missing entries based on the release's milestone. + Verify that contributors list is complete and in alphabetical order. + Merge the PR once it's ready. #. Run "Prepare Release" workflow. @@ -34,18 +87,77 @@ Making a release it won't release anything, don't worry! - Click on the "Run workflow" button - - Choose the branch you're making the release from + - Choose the long-lived branch for the version you're releasing + + This is either ``V3/develop`` or ``3.x`` branch that you will be cherry-picking changes from, + not the short-lived release branch. + - Click on the "Run workflow" button in the popover .. figure:: /images/prepare-release-workflow.png +#. Merge the automatically created PRs. + + Wait for "Prepare Release" workflow to finish and merge the PRs that it created. + +#. Create a short-lived release branch. + + .. tab:: Hotfix release + + .. note:: + + This does not apply if you're releasing from the long-lived branch + (i.e. ``V3/develop`` or ``3.x``). + + - Create a branch named ``V3/release/VERSION_TO_RELEASE_HERE`` based off + a tag of previous version. + + This can be done with the command: + + .. prompt:: + + git checkout -b V3/release/VERSION_TO_RELEASE_HERE PREVIOUS_VERSION + + - Cherry-pick the critical fix, the automated PRs, and the version bump. + - Push the branch to upstream repository (Cog-Creators/Red-DiscordBot) + + With a typical setup where ``upstream`` remote points to upstream repository + and ``origin`` points to user's fork, this can be done with the command: + + .. prompt:: + + git push -u upstream V3/release/VERSION_TO_RELEASE_HERE + + .. tab:: Maintenance release + + - Create a branch named ``V3/release/VERSION_TO_RELEASE_HERE`` based off + a tag of previous version. + + This can be done with the command: + + .. prompt:: + + git checkout -b V3/release/VERSION_TO_RELEASE_HERE PREVIOUS_VERSION + + - Cherry-pick the relevant changes, the automated PRs, and the version bump. + - Push the branch to upstream repository (Cog-Creators/Red-DiscordBot) + + With a typical setup where ``upstream`` remote points to upstream repository + and ``origin`` points to user's fork, this can be done with the command: + + .. prompt:: + + git push -u upstream V3/release/VERSION_TO_RELEASE_HERE + + .. tab:: Breaking or standard release + + This does not apply. + #. Make a new release through GitHub Releases. .. attention:: - If the currently developed version on ``V3/develop`` branch is breaking (e.g. ``3.5.0``) - and you're making a release with backports (e.g. ``3.4.13``), - double-check that the target branch isn't set to ``V3/develop``. + Remember to change the target branch when you're not releasing from ``V3/develop``! - Put the version number as tag name (i.e. ``3.4.0``) - Put the version number prepended with "v" as release title (i.e. ``v3.4.0``)