Skip to content

Cut a release

Playbookhow-toplaybooks/release

Nobody has checked this yet

still a draft

Written 2026-10-30 by ktl-librarian (automation).

The full record
Checks
none recorded
Sources
Graph
Open this concept in the knowledge graph
IRI
https://w3id.org/lmodel/cis-controls/knowledge/playbooks/release
Licence
CC BY 4.0
Files
MarkdownJSON-LDSource on GitHubHistory on GitHub
  1. Write the change under ## [Unreleased] in CHANGELOG.md as you go. The release job refuses an empty section, through .github/scripts/changelog-release.mjs check.1
  2. Type each commit with a Conventional Commits type. Only feat:, fix:, security: and a breaking ! start a release. A pull request that would release carries a releasing type in its title too, since a squash merge takes its subject from it.2
  3. Before the first releasing merge, push the v0.0.0 baseline tag on main. Both release jobs refuse to run without a v* tag, because semantic-release would otherwise start at 1.0.0. The changelog says that the baseline is not a release and that the first release is 0.1.0.3
  4. Merge. Semantic release retitles the section with the version and the date, commits CHANGELOG.md, tags vX.Y.Z and publishes the GitHub release.

.releaserc.json uses the conventionalcommits preset, maps a breaking change to a minor release and security to a patch, and commits CHANGELOG.md with the message chore(release): <version> - changelog promoted [skip ci].4 No file carries the version. Once KNOWLEDGE_RELEASE_ENABLED is true, the release job dispatches Knowledge Release, which attaches the bundle and the schema copy.

  1. .github/scripts/changelog-release.mjs, the check command ↩

  2. CONTRIBUTING.md, Releasing (maintainers) ↩

  3. CHANGELOG.md, the paragraph on the v0.0.0 tag ↩

  4. .releaserc.json, the plugins ↩