chore: prepare v0.10.0-dev - #75
Merged
Merged
Conversation
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
force-pushed
the
chore/prepare-v0.10.0-dev
branch
from
August 4, 2026 20:57
2d8a7d6 to
94aad81
Compare
Collaborator
Author
|
Rebased on Worth noting for the next cycle: v0.9.0 is tagged on the 🤖 Generated with Claude Code |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reopens development after v0.9.0, restoring the
prepare/releasepair that was skipped last cycle.An un-stamped
go runnow reports a barego608-clock v0.10.0-dev; Makefile builds are unaffected, since they stamp both fromgit describe/git log.Two deliberate choices, both easy to reverse:
-devnames the release being worked towards, matchingv0.8.0-dev,v0.7.0-devandv0.6.0-dev. It sorts afterv0.9.0and beforev0.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+devpresumes nothing, at the cost of breaking the established pattern.commitDategoes 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.goreportedv0.8.0for the nine commits between the v0.8.0 release and this cycle, because thev0.9.0-devopener was never committed. A binary built frommainclaimed to be a release it was not.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 saysv0.10.0-dev. Until #74 merges, the diff here shows its commit too; afterwards it reduces to the singleversion.gochange.🤖 Generated with Claude Code