release: cut v1.0.0

[jordonpeterson]

Bumps VERSION to 1.0 — and fixes the two things that would each have made that bump publish something other than a usable 1.0.

The tag 1.0.0 would have named nothing

VERSION holds MAJOR.MINOR; the release workflow assigns PATCH, opening a fresh line at 1. So VERSION=1.0 on its own publishes v1.0.1, and v1.0.0 — the tag an announcement names, the one uses: ...@v1.0.0 and brew install codeowners-tool@1.0.0 resolve — points at nothing, permanently. A line now opens at .0. The existing v0.0 line is untouched: its patch still increments from its own tags (v0.0.30 → v0.0.31), which is what keeps the workflow from trying to republish an immutable release.

Docs pinned a major tag that releases stop moving

README, docs/INSTALL.md and docs/LINTING.md recommend uses: jordonpeterson/codeowners-tool@v0. The release moves the major tag of the line it publishes — so the moment 1.0 opens, nothing moves v0 again and every CI consumer following those pages is frozen at v0.0.30, silently and with a green build. They now pin @v1, which this release creates.

Compatibility

The changelog's 0.x "flags, JSON fields and exit codes may change in a minor release" caveat becomes the promise 1.0 makes: stable within the major line, added to but never removed or repurposed, and moving a failure between exit classes is a major release. Stated once in CHANGELOG.md, docs/GUARANTEES.md and CONTRIBUTING.md's exit-code section. The accumulated Unreleased body becomes ## [1.0.0] - 2026-08-27.

Tests

New tools/supplychain/version_test.go, written first. It doesn't read the workflow, it runs it: the Compute next version step is extracted from release.yml and executed against fixture git repos, because the failure here is arithmetic and a regex over the YAML would have passed on the broken version.

• first release on a line is .0 — failed with v1.0.1, and against the committed VERSION too
• later releases still continue from the tags already on the line (v0.0.30 → v0.0.31, v1.0.0 → v1.0.1)
• docs pin the major tag releases still move, with the expected major derived from VERSION rather than hardcoded, so the two cannot drift apart at the next major

make vet, go test ./... and make docs are clean; no BEHAVIOR.md drift, since gendocs walks internal/* only.

What merging does

The VERSION path filter triggers release.yml, which publishes v1.0.0 with binaries, checksums and a build-provenance attestation, then creates the v1 tag the docs now point at. Worth a look before merge: the date on the changelog heading, and whether everything under it is what you want 1.0 to commit to.

---

Generated by Claude Code

[Copilot]

🔵 Needs a closer look

A modified action test now refers to @v1 but still stubs/expects a v0.* “latest” tag, making the test inconsistent with the new 1.x release line.

Pull request overview

This PR prepares the repository for the v1.0.0 release by updating the manually-maintained VERSION line, fixing the release workflow so the first release on a new line is .0, and updating documentation/tests to recommend pinning the moving major tag (@v1) instead of @v0.

Changes:

• Bump VERSION to 1.0 and adjust release.yml to start new MAJOR.MINOR lines at patch 0 (so v1.0.0 exists).
• Update docs and action messaging to recommend uses: ...@v1 (major tag that releases move).
• Add supply-chain tests that execute the workflow’s version computation logic against fixture git repos/tags.

File summaries

File	Description
VERSION	Bumps release line to 1.0.
.github/workflows/release.yml	Starts new lines at patch 0 and updates major-tag movement commentary.
tools/supplychain/version_test.go	Executes the workflow’s “Compute next version” step against fixture repos to prevent vX.Y.0 gaps and doc-pin drift.
tools/action/version_test.go	Updates major-tag pin test to @v1 (needs a small follow-up fix: the stubbed “latest” tag should be v1.*).
tools/action/setup.sh	Updates messaging/comments to reference @v1 and v1.0.0 examples.
tools/action/manifest_test.go	Updates assertions/messages to reference the @v1 major pin.
action.yml	Updates version input example to v1.0.0.
README.md	Updates CI usage guidance from @v0 to @v1.
docs/INSTALL.md	Updates action pin and input table text to @v1.
docs/LINTING.md	Updates CI example pin to @v1.
install.sh	Updates example pinned VERSION to v1.0.0.
docs/GUARANTEES.md	Adds explicit 1.0 compatibility guarantee statement.
CONTRIBUTING.md	Clarifies that post-1.0 exit-class moves are major releases.
CHANGELOG.md	Promotes 1.0 stability promise and rolls Unreleased into 1.0.0 dated 2026-08-27.

Review details

Suppressed comments (1)

tools/action/version_test.go:84

• This test now asserts behavior for the recommended major pin @v1, but it still stubs/expectes a v0.0.28 “latest” tag. That makes the test description misleading and weakens the intended guarantee for the 1.x line; the stubbed GH response and the expected installed VERSION should be a v1.* tag (e.g. v1.0.0 for this release).

	r := run{actionRef: "v1", withGH: true, ghTag: "v0.0.28", stubVersion: "v0.0.28"}.exec(t)
	if r.exitCode != 0 {
		t.Fatalf("setup.sh exited %d, want 0\n%s", r.exitCode, r)
	}
	if got := r.installed["VERSION"]; got != "v0.0.28" {

• Files reviewed: 14/14 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.