WIP: release: 1.2.0 #16

Closed

mikluko wants to merge 1 commit from mikluko/octant/release-1.2.0 into mikluko/octant/1718-examples-live

mikluko commented

2026-09-05 16:34:24 +00:00

(Migrated from github.com)

Top of stack #15. Merging the stack cuts v1.2.0; merging either PR below it alone cuts nothing, because [Unreleased] names no version.

#14  unreadable-version, split out of heading-form   behaviour
#13  examples rebuilt from a live adoption           documentation
#15  this                                            ceremony

What it does

The three edits the contract asks for, and no code:

## [Unreleased] renamed to ## [1.2.0] - 2026-09-05.
A fresh, empty ## [Unreleased] opened above it.
[Unreleased] repointed at v1.2.0...HEAD, and a [1.2.0] compare link added.

Plus this repository's own fourth: action.yaml runs ghcr.io/mikluko/action-changelog:v1.2.0. It has to name an immutable image at the moment it is committed, because a workflow pinning this action by SHA reads that file as it stands at that commit and nothing is rewritten onto main afterwards. TestVersionMatchesTheChangelog holds the two together.

Why 1.2.0

Read off git tag --sort=-v:refname, which is v1.1.0, rather than off the changelog's newest heading. The two drift, and only the tags decide what already-tagged is checked against.

Minor rather than patch: unreadable-version is new behaviour, compatible. The output change beneath it is a fix, but a release takes the highest level in it.

What the release will contain

unreadable-version and the output fix from #14, both already written under [Unreleased] there. #13 is documentation and writes no entry, which is this repository's standing practice for examples: a version that changes no behaviour is noise.

Verification

go test ./... green across all six packages, go vet ./... and gofmt -l clean. TestVersionMatchesTheChangelog passes with GITHUB_REF_NAME=v1.2.0, which is the tag the merge will cut.

The action run against this repository's own changelog reports what the release workflow needs:

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

Merging

From a checkout of this repository:

gh stack merge --squash 15

All three, atomically, from the top. Merging #14 or #13 by hand instead breaks everything above it, since a squash rewrites the commit the PRs above are based on.

AI assistance

Written by Claude Code (Opus 5).

**Top of stack #15.** Merging the stack cuts `v1.2.0`; merging either PR below it alone cuts nothing, because `[Unreleased]` names no version. ``` #14 unreadable-version, split out of heading-form behaviour #13 examples rebuilt from a live adoption documentation #15 this ceremony ``` ## What it does The three edits the contract asks for, and no code: 1. `## [Unreleased]` renamed to `## [1.2.0] - 2026-09-05`. 2. A fresh, empty `## [Unreleased]` opened above it. 3. `[Unreleased]` repointed at `v1.2.0...HEAD`, and a `[1.2.0]` compare link added. Plus this repository's own fourth: `action.yaml` runs `ghcr.io/mikluko/action-changelog:v1.2.0`. It has to name an immutable image at the moment it is committed, because a workflow pinning this action by SHA reads that file as it stands at that commit and nothing is rewritten onto `main` afterwards. `TestVersionMatchesTheChangelog` holds the two together. ## Why 1.2.0 Read off `git tag --sort=-v:refname`, which is `v1.1.0`, rather than off the changelog's newest heading. The two drift, and only the tags decide what `already-tagged` is checked against. Minor rather than patch: `unreadable-version` is new behaviour, compatible. The output change beneath it is a fix, but a release takes the highest level in it. ## What the release will contain `unreadable-version` and the output fix from #14, both already written under `[Unreleased]` there. #13 is documentation and writes no entry, which is this repository's standing practice for examples: a version that changes no behaviour is noise. ## Verification `go test ./...` green across all six packages, `go vet ./...` and `gofmt -l` clean. `TestVersionMatchesTheChangelog` passes with `GITHUB_REF_NAME=v1.2.0`, which is the tag the merge will cut. The action run against this repository's own changelog reports what the release workflow needs: ``` valid=true version=1.2.0 already-tagged=false latest-tag=v1.1.0 ``` ## Merging From a checkout of this repository: ``` gh stack merge --squash 15 ``` All three, atomically, from the top. Merging #14 or #13 by hand instead breaks everything above it, since a squash rewrites the commit the PRs above are based on. ## AI assistance Written by Claude Code (Opus 5).