Synthetic release dry run: commits in, version and changelog out, repeat run creates nothing

An invented starting point

Synthetic example: every name, number and result below is invented for illustration. It is not a client's work, a measurement or a delivery by us.

Assume the last released version of an invented project is 1.4.2 and four synthetic scratch branches each hold a different set of commits since that release. The agreed table, written before the dry run, says which version each set should produce. The rules applied are those of the Conventional Commits convention: a fix is a patch, a feat is a minor, and a breaking change is a major, while docs, chore and test commits have no effect on their own.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

set | commits since 1.4.2                                   | expected next version
A   | fix(parser): handle empty input; docs: update guide        | 1.4.3
B   | feat(api): add export option; fix(ui): align label         | 1.5.0
C   | chore: update lint config; test: add case                  | no release
D   | feat(api)!: remove legacy endpoint; feat(ui): new filter   | 2.0.0

Compare the dry run with the table

In this invented run, assume the dry run reports exactly the versions above and creates no tag. A difference would point to the history the tool could see or the convention the messages followed, not to chance. Set C is the useful one: a set of commits with no release-worthy change must produce no release, and a tool that proposes a version there is applying a different rule.

• A dry run creates nothing.
• A no-release set must propose no version.
• A mismatch is evidence about history or convention.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

set | dry run reported | matches table
A   | 1.4.3              | yes
B   | 1.5.0              | yes
C   | no release         | yes
D   | 2.0.0              | yes

The approved run and the repeat run

Assume your approver starts one real release from the release branch for set B. The pipeline creates one tag, v1.5.0, and one release record whose notes group the two changes by kind, each listed once. The pipeline is then run again with no new commits and creates nothing, because the tag already exists and there are no new changes. A run started from any other branch creates nothing either. These three results are the acceptance evidence for this part, and none of them has actually happened: this is an invented sequence.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

run                                   | tag created | release record
approved run from release branch (set B) | v1.5.0      | 1, notes grouped: Added, Fixed
repeat run, no new commits             | none        | none
run from another branch                | none        | none

What this example proves, and the next step

Synthetic example: every name, number and result below is invented for illustration. It is not a client's work, a measurement or a delivery by us. Nothing here was built, tagged or released; the version arithmetic follows the cited rules and was checked as arithmetic only.

For a real repository, the fixed job starts at £595, untested, after a quote based on your branch layout, merge style and current release steps, and is paid after the dry run, the approved release and the repeat run pass and you sign off. Publishing to a package registry is excluded unless agreed in writing.