122 lines
4.6 KiB
Markdown
122 lines
4.6 KiB
Markdown
Run the pre-release checklist for this project. Work through all three phases
|
||
in order, pausing for explicit confirmation at each decision point before
|
||
proceeding. Never create a branch, commit, tag, or push without approval.
|
||
|
||
---
|
||
|
||
## Phase 1 — Determine next release
|
||
|
||
1. Run `git status` and confirm the working tree is clean and on `master`.
|
||
If not, stop and report the problem.
|
||
|
||
2. Run `git tag --sort=-v:refname` to list existing tags. Identify the most
|
||
recent tag matching `v*.*.*-*` and extract its stadium codename.
|
||
|
||
3. Read the A–Z stadium table from `CHANGELOG.md` to find the next stadium:
|
||
- **No tags yet**: start at `A` (first stadium in the table).
|
||
- **Normal case**: use the stadium that follows the last used codename
|
||
alphabetically. If letters were skipped, pick the next after the
|
||
highest existing codename — do not backfill gaps.
|
||
- **Last codename is `Z`** (Zentralstadion): the list is finite. Stop and
|
||
refer to ADR 0012 for guidance on extending or revisiting the convention.
|
||
|
||
4. Read the `[Unreleased]` section of `CHANGELOG.md` and infer the version
|
||
bump using these rules (applied in order — first match wins):
|
||
- Any entry contains the word **BREAKING** (case-insensitive), a
|
||
`BREAKING CHANGE:` token in a commit footer, or a `!` suffix after
|
||
the commit type/scope (e.g. `feat!:` or `feat(scope)!:`) → **major** bump
|
||
- Any `### Added` subsection has entries → **minor** bump
|
||
- Otherwise (only `### Changed`, `### Fixed`, `### Removed`) → **patch** bump
|
||
|
||
5. Compute the next version by applying the bump to the current latest tag's
|
||
semver (e.g. `v2.1.0-dusseldorf` + minor → `2.2.0`).
|
||
|
||
6. Present a summary for confirmation before continuing:
|
||
- Last tag and stadium
|
||
- Next version and stadium codename
|
||
- Bump type and the reasoning (what triggered it)
|
||
- Proposed tag: `vX.Y.Z-{stadium}`
|
||
- Proposed branch: `release/vX.Y.Z-{stadium}`
|
||
|
||
**Wait for explicit approval before proceeding to Phase 2.**
|
||
|
||
---
|
||
|
||
## Phase 2 — Prepare release branch
|
||
|
||
1. Create branch `release/vX.Y.Z-{stadium}` from `master`.
|
||
|
||
2. Edit `CHANGELOG.md`:
|
||
- Replace `## [Unreleased]` with `## [X.Y.Z - StadiumName] - YYYY-MM-DD`
|
||
(use today's date; use the stadium's display name from the table, e.g.
|
||
"Bernabeu", "Centenario").
|
||
- Consolidate duplicate subsection headings (e.g. two `### Added` blocks
|
||
should be merged into one).
|
||
- Add a new empty `## [Unreleased]` section at the top (above the new
|
||
versioned heading) with the standard subsections.
|
||
- Update the compare links at the bottom of the file:
|
||
- `[unreleased]` → `.../compare/vX.Y.Z-{stadium}...HEAD`
|
||
- Add `[X.Y.Z - StadiumName]` → `.../compare/v{prev-tag}...vX.Y.Z-{stadium}`
|
||
|
||
3. Show the full diff of `CHANGELOG.md`.
|
||
|
||
4. If `coderabbit` CLI is installed, run `coderabbit review --type uncommitted --prompt-only`
|
||
on the uncommitted CHANGELOG changes:
|
||
- If actionable/serious findings are reported, stop and address them before proceeding.
|
||
- If only nitpick-level findings, report them and continue.
|
||
- If `coderabbit` is not installed, skip with a note.
|
||
|
||
5. Propose this commit message:
|
||
|
||
```text
|
||
docs(changelog): prepare release notes for vX.Y.Z-{stadium} (#issue)
|
||
```
|
||
|
||
**Wait for explicit approval before committing.**
|
||
|
||
6. Run `dotnet build --configuration Release` — must succeed.
|
||
|
||
7. Run `dotnet test --settings .runsettings` — all tests must pass.
|
||
|
||
8. If `dotnet csharpier` is available, run `dotnet csharpier --check .` — must pass
|
||
(run `dotnet csharpier .` to auto-fix). Skip with a note if not installed.
|
||
|
||
9. Stage `CHANGELOG.md` and commit using the approved message from step 5.
|
||
|
||
10. Propose opening a PR from `release/vX.Y.Z-{stadium}` into `master`.
|
||
**Wait for explicit approval before opening.**
|
||
|
||
11. Open the PR with:
|
||
- Title: `docs(changelog): prepare release notes for vX.Y.Z-{stadium}`
|
||
- Body summarising what is included in this release.
|
||
|
||
---
|
||
|
||
## Phase 3 — Tag and release
|
||
|
||
1. Wait — do not proceed until the user confirms:
|
||
- CI is green
|
||
- The PR has been merged into `master`
|
||
|
||
2. Once confirmed, run:
|
||
```bash
|
||
git checkout master && git pull origin master
|
||
```
|
||
and show the resulting `git log --oneline -3`.
|
||
|
||
3. Propose the annotated tag:
|
||
```bash
|
||
git tag -a vX.Y.Z-{stadium} -m "Release X.Y.Z - StadiumName"
|
||
```
|
||
|
||
**Wait for explicit approval before creating the tag.**
|
||
|
||
4. Create the tag, then propose:
|
||
```bash
|
||
git push origin vX.Y.Z-{stadium}
|
||
```
|
||
|
||
**Wait for explicit approval before pushing.** Remind the user that pushing
|
||
the tag triggers the CD workflow which will build, publish the Docker image,
|
||
and create the GitHub Release.
|