Skip to content

chore: prepare v0.10.0-dev - #75

Merged
tobbee merged 1 commit into
mainfrom
chore/prepare-v0.10.0-dev
Aug 4, 2026
Merged

chore: prepare v0.10.0-dev#75
tobbee merged 1 commit into
mainfrom
chore/prepare-v0.10.0-dev

Conversation

@tobbee

@tobbee tobbee commented Aug 4, 2026

Copy link
Copy Markdown
Collaborator

Reopens development after v0.9.0, restoring the prepare/release pair that was skipped last cycle.

commitVersion = "v0.10.0-dev"  // was v0.9.0
commitDate    = ""             // was the release commit's timestamp

An un-stamped go run now reports a bare go608-clock v0.10.0-dev; Makefile builds are unaffected, since they stamp both from git describe / git log.

Two deliberate choices, both easy to reverse:

  • -dev names the release being worked towards, matching v0.8.0-dev, v0.7.0-dev and v0.6.0-dev. It sorts after v0.9.0 and before v0.10.0. This encodes an assumption that the next release is a minor — true for every release so far (0.5 → 0.9, no patch releases). If 0.9.x could be next, v0.9.0+dev presumes nothing, at the cost of breaking the established pattern.
  • commitDate goes back to empty. A date belongs to a release, and a development build was not cut from one — leaving v0.9.0's timestamp in place would have every dev build reporting the previous release's date as its own.

Why it matters: version.go reported v0.8.0 for the nine commits between the v0.8.0 release and this cycle, because the v0.9.0-dev opener was never committed. A binary built from main claimed to be a release it was not.

⚠️ Merge order

Based on chore/release-v0.9.0 (#74), so it must land after that PR merges and after v0.9.0 is tagged. Merging this first — or before tagging — would leave the tag pointing at a commit that already says v0.10.0-dev. Until #74 merges, the diff here shows its commit too; afterwards it reduces to the single version.go change.

🤖 Generated with Claude Code

internal/version.go: v0.9.0 -> v0.10.0-dev, and commitDate back to empty.

Reopens development after v0.9.0, restoring the prepare/release pair that was skipped last cycle -- version.go reported v0.8.0 for the nine commits between the v0.8.0 release and this one, so a binary built from main claimed to be a release it was not.

-dev names the release being worked towards, matching v0.8.0-dev, v0.7.0-dev and v0.6.0-dev before it, and sorting after v0.9.0 but before v0.10.0. The next minor is the assumption the suffix encodes; if 0.9.x turns out to be the next release instead, this is the line to change.

commitDate goes back to empty on purpose. A date belongs to a release, and a development build was not cut from one, so an un-stamped go run now reports a bare v0.10.0-dev rather than carrying v0.9.0's date around. Makefile builds are unaffected -- they stamp both from git describe and git log.
@tobbee
tobbee force-pushed the chore/prepare-v0.10.0-dev branch from 2d8a7d6 to 94aad81 Compare August 4, 2026 20:57
@tobbee

tobbee commented Aug 4, 2026

Copy link
Copy Markdown
Collaborator Author

Rebased on main now that #74 has merged (085d740) and v0.9.0 is tagged. The release commit dropped out as already-applied, so this PR is down to the single version.go change and the merge-order caveat in the description no longer applies — it's ready whenever you are.

Worth noting for the next cycle: v0.9.0 is tagged on the chore(release) commit itself, whereas v0.8.0 landed on a docs commit that followed it. This one is the tidier habit.

🤖 Generated with Claude Code

@tobbee
tobbee merged commit 061907e into main Aug 4, 2026
7 checks passed
@tobbee
tobbee deleted the chore/prepare-v0.10.0-dev branch August 4, 2026 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant