Release

How a version of the tool is cut and what it publishes (16 passages, no note): the npm (7 passages, no note) packages (23 passages, no note) under one shared version number and the preset (note: Preset), the container image (5 passages, no note) tagged with the version and latest, a git (24 passages, no note) tag (18 passages, no note) v<major>.<minor>.<patch> on the main branch (6 passages, no note), a release (note: Release) whose notes (note: Note) are the changelog entries with the tarball (4 passages, no note) of every package and the standalone binaries (4 passages, no note) as assets (5 passages, no note), and the mirrors of the GitHub (10 passages, no note) action (10 passages, no note) and the GitLab component (46 passages, no note) at the same version. Every form (52 passages, no note) of one version names the same commit (29 passages, no note): the tag, the packages on npm, the image (18 passages, no note), the action, the component and the pre (3 passages, no note)-commit hook (4 passages, no note). Versions follow semantic versioning; before 1.0.0 a minor version may break compatibility and says so, a patch never does. The release guide is the contract (note: Contract); the one decision (62 passages, no note) that stays human is the merge (27 passages, no note) of the version pull request (31 passages, no note), and the publications (40 passages, no note) to the registries (11 passages, no note) stay disabled until the maintainer (note: Maintainer) enables them.

1. Every pull request that changes a published package carries a changeset (5 passages, no note): the packages it touches, the bump and one sentence (25 passages, no note) for the changelog; the pipeline (note: Pipeline) refuses a pull request without one.
2. On every push to the main branch that carries a changeset, the pipeline opens or refreshes the version pull request: the versions are bumped, every changelog is updated from the sentences the pull requests wrote, the consumed changeset files are deleted, the lock file (note: Lock) and the version pins (note: Pinned page) of the action, the component and the hook are rewritten (5 passages, no note); a changelog entry a user would not understand is rewritten in its changeset on the main branch, never in the pull request.
3. The maintainer reads the version pull request and merges it: this is the decision to release.
4. The release workflow (9 passages, no note) tags the merge commit v<x.y.z>, builds (note: Build) the standalone binaries on three platforms (4 passages, no note), packs (note: Language pack) every published package, verifies (6 passages, no note) the licence inventory (4 passages, no note), writes the checksums (4 passages, no note) and creates the release from the tag with the changelog entries of the version as its notes and the binaries (7 passages, no note), the tarballs, the checksums and the inventory (5 passages, no note) as its assets; the manifest (4 passages, no note) of every package has been checked on every change to ship neither its sources (note: Source), nor its tests, nor its fixtures (note: Golden corpus).
5. The image workflow builds the container image from the tag, compares a build inside the container (12 passages, no note) with one outside and measures (6 passages, no note) the image; once its publication is enabled (5 passages, no note) it pushes the image under the version and latest, and the maintainer copies its size (12 passages, no note) into the release notes.
6. Once the npm publication is enabled, the publish job takes the tarballs attached to the release, verifies them against the checksums and publishes them in dependency (8 passages, no note) order with provenance (note: Provenance), under the tag latest for a plain version and next or rc for a prerelease; it then lints (note: Lint) the faulty corpus (note: Corpus) through the published command (21 passages, no note) line from an empty folder and through the binary of the release, and the two reports (47 passages, no note) must match (note: Occurrence).
7. The release notes are completed with the npm page of every package and the digest of the image when it is on the registry; the action repository (note: Knowledge repository) and the component project (4 passages, no note) receive the version, each when its token exists, the action with its major tag moved (6 passages, no note) to the version.