Updating release docs and adding cherry-pick process docs
@@ -275,14 +275,14 @@ This section contains information on releasing Fleet.
### Release Candidates
-1. Checkout `master`
+1. Checkout the release branch (e.g., `release-0.4`) or create it based off of the latest `master` branch. The branch name should be the first 2 parts of the semantic version with `release-` prepended.
1. Use `git tag` and append the tag from the **Pre-Release** section with `-rcX` where `X` is an unsigned integer that starts with `1` (if `-rcX` already exists, increment `X` by one)
### Full Releases
1. Open a draft release on the GitHub releases page
1. Send draft link to maintainers with view permissions to ensure that contents are valid
-1. Create GitHub release and create a new tag while doing so (using the tag from the **Pre-Release** section)
+1. Create GitHub release and create a new tag on the appropriate release branch while doing so (using the tag from the **Pre-Release** section)
### Post-Release
@@ -291,6 +291,16 @@ This section contains information on releasing Fleet.
---
+## Cherry Picking Bug Fixes To Releases
+
+With releases happening on release branches, there are times where a bug fix needs to be handled on the `master` branch and pulled into a release that happens through a release branch.
+
+All bug fixes should first happen on the `master` branch.
+
+If a bug fix needs to be brought into a release, such as during the release candidate phase, it should be cherry picked from the `master` branch to the release branch via a pull request. The pull request should be prefixed with the major and minor version for the release (e.g., `[0.4]`) to illustrate it's for a release branch.
+
+---
+
## Attributions
- ASCII charts created with [asciiflow](https://asciiflow.com/)
