release: 1.2.0 #26

Merged

mikluko merged 1 commit from mikluko/octant/cut-1.2.0 into main

2026-09-07 07:28:17 +00:00

mikluko commented

2026-09-07 07:20:35 +00:00

(Migrated from github.com)

Cuts 1.2.0. Two files, five lines, per the ceremony in the README: CHANGELOG.md gains the dated entry and action.yaml names the image built for it. go test ./... fails while those disagree.

The tag is not cut here. Merging is what cuts it, from this entry.

What the action says about this pull request

valid=true
version=1.2.0
already-tagged=false
prerelease=false
latest-tag=v1.1.0

So the release workflow will publish the image, cut v1.2.0, create the release from notes, and move v1.

What 1.2.0 carries

A strict Semantic Versioning 2.0.0 parser, replacing golang.org/x/mod/semver outright — that dependency is out of go.mod. Its accepted set is checked against the specification's own suggested regex as a differential oracle: 54 valid forms, 42 invalid ones each carrying the rule it breaks, and three pinned departures where this project is deliberately narrower.

Three new checks, taking the register from fifteen to eighteen:

check	default	what it catches
`unreadable-version`	`error`	a heading naming no readable version, which used to be reported only by `heading-form` — and switching that off turned a loud rejection into a release cut from the wrong entry
`date-mismatch`	`error`	a released entry dated something other than the day its tag was cut
`oci-incompatible-version`	`error`	a version that is valid SemVer and cannot be an OCI tag

A SemVer compliance section in the README, stating what four named tools do with a version — every claim read from a primary source and tagged with the version it was read against.

The release-branch example rewritten to teach what its adopter actually settled on: the changelog names the release it heads for and never an attempt, candidates are numbered per pull-request revision, and a release branch has no push trigger.

Why minor and not major

On this repository's own precedent: 1.1.0 shipped undated-entry at error, and a new error-default check is the same shape of change.

Two things a consumer can see are narrowings rather than additions, and they are in Changed rather than buried:

## [v1.2.3] no longer names a version. The leading v belongs to a tag namespace, not to the specification, and a heading is not a tag.
date-mismatch and oci-incompatible-version can redden a build that was green on a document nobody edited. Both are switchable off in off:.

If you'd rather this were 2.0.0, it is a one-line change to both files before merging.

Cuts `1.2.0`. Two files, five lines, per the ceremony in the README: `CHANGELOG.md` gains the dated entry and `action.yaml` names the image built for it. `go test ./...` fails while those disagree. **The tag is not cut here.** Merging is what cuts it, from this entry. ## What the action says about this pull request ``` valid=true version=1.2.0 already-tagged=false prerelease=false latest-tag=v1.1.0 ``` So the release workflow will publish the image, cut `v1.2.0`, create the release from `notes`, and move `v1`. ## What 1.2.0 carries **A strict Semantic Versioning 2.0.0 parser**, replacing `golang.org/x/mod/semver` outright — that dependency is out of `go.mod`. Its accepted set is checked against the specification's own suggested regex as a differential oracle: 54 valid forms, 42 invalid ones each carrying the rule it breaks, and three pinned *departures* where this project is deliberately narrower. **Three new checks**, taking the register from fifteen to eighteen: | check | default | what it catches | |---|---|---| | `unreadable-version` | `error` | a heading naming no readable version, which used to be reported only by `heading-form` — and switching that off turned a loud rejection into a release cut from the wrong entry | | `date-mismatch` | `error` | a released entry dated something other than the day its tag was cut | | `oci-incompatible-version` | `error` | a version that is valid SemVer and cannot be an OCI tag | **A SemVer compliance section** in the README, stating what four named tools do with a version — every claim read from a primary source and tagged with the version it was read against. **The `release-branch` example rewritten** to teach what its adopter actually settled on: the changelog names the release it heads for and never an attempt, candidates are numbered per pull-request revision, and a release branch has no push trigger. ## Why minor and not major On this repository's own precedent: 1.1.0 shipped `undated-entry` at `error`, and a new error-default check is the same shape of change. Two things a consumer can see are narrowings rather than additions, and they are in `Changed` rather than buried: - `## [v1.2.3]` no longer names a version. The leading `v` belongs to a tag namespace, not to the specification, and a heading is not a tag. - `date-mismatch` and `oci-incompatible-version` can redden a build that was green on a document nobody edited. Both are switchable off in `off:`. If you'd rather this were `2.0.0`, it is a one-line change to both files before merging.