vscan

Overview ¶

Reports, for every tagged Go module whose default branch has moved past its latest tag, what the next version number should be -- DERIVED from the public API rather than guessed.

tagscan says 280 of 333 tagged modules carry merged work `go get` cannot reach. Choosing a bump for each by hand is 280 chances to publish a number that lies about compatibility. golang.org/x/exp/cmd/gorelease answers the same question from the API diff, so this asks it and reports what it said.

⛔ IT ASKS ONCE PER PLATFORM, AND THIS IS NOT A REFINEMENT. gorelease reads the package under ONE build context. Removing New from go-xrkit/depth3d's !darwin file -- a break for every Linux consumer -- was measured on a darwin host as:

GOOS=darwin    Suggested version: v0.1.1    (a PATCH)
GOOS=linux     Suggested version: v0.2.0    incompatible changes: 1
GOOS=windows   Suggested version: v0.2.0    incompatible changes: 1

One reading would have published a patch over a broken API. The verdict here is the HIGHEST suggestion across the platforms asked, and a module where any platform could not be read is reported as unread, never as agreed.

⛔ A MINOR SUGGESTION IS NOT PROOF THE API GREW. gorelease bumps the minor for THREE reasons, and its source is the only place that says so:

} else if r.haveCompatibleChanges || (r.haveIncompatibleChanges && major == "0") || r.requirementsChanged() {

and requirementsChanged() is true when a requirement moved up a MINOR, when one was added, or when the go directive rose. go-simd/floats suggests v0.2.0 with no changes section printed at all: its only cause is golang.org/x/sys v0.46.0 -> v0.48.0. A first version of this labelled that "additions only", which the tool never said -- a story invented to fill a column. The three causes are now reported apart, and the absence of both sections is reported as what it is: the exported API did not change.

⛔ A FROZEN TAG IS NOT AN ABSENT ONE. Eight modules carry a tag that `git tag --merged` cannot see, because a history rewrite left it on an orphaned line -- GitHub answers "No common ancestor". A first version filed them under "never tagged", which is false and dangerous in the one direction that matters: go-filesystems/xfs v0.1.0 is published and required by SIX repositories, and "never tagged" invites cutting it again. They get their own section. gorelease still answers for them, because it fetches the base from the module proxy and never consults git ancestry.

⛔ IT READS THE DEFAULT BRANCH, NEVER THE CHECKOUT. A first version ran gorelease where the clone happened to be, and go-simd/floats -- six commits behind -- came back v0.1.4 against v0.2.0 from its own branch head. A version derived from stale code is worse than no answer, because it looks like one. Each module is fetched, then materialised at origin's default ref, which also disposes of gorelease's refusal to read an unclean tree.

⛔ IN v0.x THE NUMBER DOES NOT TELL YOU WHETHER SOMETHING BROKE. Adding an exported symbol and removing one both suggest v0.2.0, because semver gives v0 no major slot. So the incompatible-changes section is recorded SEPARATELY from the number, and a module with one is never called safe.