# Release process ## Motivation We need to backport important bug fixes to supported releases. Where **supported releases** just means the most recent minor, until such time as we leave alpha or are required to support multiple lines. **Scope of acceptable fixes** means bug fixes and not features, with some discretion applied by the core-maintainer team. ## Branching strategy 1. Cartographer's strategy is to work on new features on the `main` branch for the next targeted release, eg 0.5, or 0.6 etc 2. We take a release branch once all features are complete on main. When we take a new #.#.x release we name the branch `release/#.#.x`. For example: `release/0.4.x` 3. We continue to patch and add new feature on main, backporting (cherry-pick) release-specific fixes to our release branch. ## Cutting releases Take our tags from the release branch. The github actions will ensure that the tag branched off the correct release branch. ## Backporting rules Currently we don't have any support lines, so we simply backport fixes to the most recent minor. # Action items: 1. [ ] Update github actions to enforce **releases-must-come-from-release-branch** 2. [x] Cut branch release/0.4.x from the 0.4.0 tag.