Release Playbook
Purpose
Define the operational release flow from freeze to tag for DSAMbayes v1.2.2, including rollback and hotfix handling.
Audience and roles
- Release owner (
cshaw): drives the checklist, evidence pack, and final go or no-go call. - Maintainers: execute gates, review failures, and approve release PRs.
- Reviewers: verify evidence and sign off risk acceptance.
Release inputs
Release work starts only when these inputs are ready:
CHANGELOG.mdreflects the release candidate contents.DESCRIPTIONhas the intended release version.- Required docs pages for quality and runner workflows are in place.
- Candidate commit hash is identified on
mainormaster.
Step-by-step flow
1. Freeze the release candidate
Actions:
- Announce code freeze window and candidate commit hash.
- Stop merging non-release changes until gate outcome is known.
- Confirm release scope is documentation and refactor changes planned for
v1.2.2.
Expected outcome: one stable candidate commit is selected for gate execution.
2. Prepare local release environment
Actions:
- Create repo-local paths and environment variables.
- Install local package into
.Rlib.
Commands:
Expected outcome: release checks run in a reproducible local environment.
3. Run mandatory quality gates
Execute gates QG-1 to QG-7 from Quality Gates in order.
Commands:
Expected outcome: all mandatory gates pass with exit code 0, with no unresolved WARNING or ERROR.
4. Confirm CI workflow status
Actions:
- Confirm
.github/workflows/R-CMD-check.yamlis green for the candidate commit. - Confirm
.github/workflows/pkgdown.yamlbuild step is green for the candidate commit. - For non-PR release flow, confirm pkgdown deploy step eligibility and permissions.
Expected outcome: CI evidence aligns with local gate outcomes.
5. Finalise release metadata
Actions:
- Re-check
DESCRIPTIONversion andCHANGELOG.mdtop section. - Ensure release notes correspond to the candidate commit only.
- Commit final metadata edits if needed.
Expected outcome: version metadata and release notes are internally consistent.
6. Build release evidence and sign-off record
Actions:
- Assemble logs and artefacts defined in Release Evidence Pack.
- Record gate outcomes and decision in Release Sign-off Template.
- Capture any accepted
NOTErationale fromrcmdcheck.
Expected outcome: auditable evidence bundle is complete and signed.
7. Create and push release tag
Create an annotated tag for the approved version and push it.
Commands:
Expected outcome: release tag v1.2.2 exists on remote and points to the signed-off commit.
8. Publish release and verify post-release state
Actions:
- Publish the GitHub release from tag
v1.2.2. - Confirm
pkgdown.yamlruns on releasepublishedevent. - Confirm deployed docs are up to date.
Expected outcome: release record and documentation deployment are complete.
Go or no-go rules
NO-GOif any mandatory quality gate fails.NO-GOif release evidence or sign-off template is incomplete.NO-GOif version metadata and changelog are inconsistent.GOonly when all gates pass and sign-off is recorded.
Rollback procedure
Use this procedure if a release must be withdrawn.
Case A: tag created, release not published
Actions:
- Delete the local tag.
- Delete the remote tag.
- Open a corrective PR and restart gate execution.
Commands:
Expected outcome: withdrawn tag is removed and cannot trigger downstream release steps.
Case B: release published
Actions:
- Mark the published release as superseded with a clear incident note.
- Do not rewrite history on
mainormaster. - Cut a hotfix release using the hotfix path below.
Expected outcome: users are directed to a corrected patch release.
Hotfix path
Use this path for a defect found after publication.
- Branch from the released tag.
- Apply the minimal fix and update release metadata.
Actions:
- bump
DESCRIPTIONversion to1.2.1 - add a
DSAMbayes 1.2.1section at top ofCHANGELOG.md
- Re-run mandatory gates (
QG-1toQG-7). - Obtain sign-off with explicit incident reference.
- Tag and publish
v1.2.1.
Commands:
Expected outcome: defect is remediated in a new immutable patch release.