How to plan a release
The steps a team can follow from the first list of changes to the day it ships.
A release goes better when everyone knows what is in it, who owns each part, and when it ships. These are the four steps a team can follow, from the first list to the day it goes out.
Write down the scope
Start with a short list of what the release changes. Keep each line to one change, and link it to its ticket, so anyone can see the detail.
- New features, each with one owner.
- Fixes that people asked for.
- Anything that changes how people sign in or pay.
Set the dates
Pick the day it ships first, then work back from it. Leave a few days between the last change and the release, for testing.
- The last change is merged.
- Testing starts on the release branch.
- The release notes are written.
- The release ships.
When a date slips
Keep the days for testing, and move the release day instead. Say the new date in the same place you said the first one.
Move the release, not the testing.
Release checklist
Check the build
Run the checks on the release branch with npm run check. Every check must pass before the build goes out.
git switch -c release/2.4
npm ci
npm run check
npm run buildShare the release notes
Post the notes where people already look, like the changelog and the team channel. Link each line to its docs, and name who to ask about it.