Help us shape the future of Go! Take the 2026 Go Developer Survey

release

command
v0.6.7 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Oct 3, 2026 License: MIT Imports: 8 Imported by: 0

Documentation

Overview

Command release prepares a lockstep release of every published rig module.

rig is twelve modules in one repository, and they are not independent: the binary links auth, files, migrate, notify, presence and runtime, and it generates code that imports them. A rig that generates against a runtime API released under a different number is a rig nobody can use, so there is one version for all twelve, and one commit that sets it everywhere.

What this does, in order:

  1. reads go.work for the modules to release — the use directives that are not examples, so a new module is included by being buildable rather than by being remembered here;
  2. refuses to continue if any of them still replaces a sibling, because a replace directive is exactly what a published module may not carry;
  3. rewrites every intra-repository requirement to the new version;
  4. commits if that rewrote anything, and tags either way: vX.Y.Z for the root, <dir>/vX.Y.Z for the rest. A version already in place is not a version already released — the tags are what release it.

It does not tidy, and that is not an oversight: `go mod tidy` is a single-module operation that resolves from the proxy and ignores the workspace, so between the rewrite and the tag it would be asked for a version that does not exist yet and would fail. The order is rewrite, tag, push the tags, and only then tidy — which is what `make release` prints at the end.

Pushing and verifying are separate modes rather than separate commands, because both need the same list of modules this reads out of go.work:

--push     the submodule tags in one push, then the root tag by itself.
           GitHub creates no push event for a batch of more than three
           tags, so pushing all of them fires no release workflow at all.
--verify   whether the tag produced a release: the tags on origin, the run
           it was supposed to trigger, the GitHub release and its archives,
           npm, and a real `go install`. A workflow that never started looks
           exactly like one that succeeded, and nothing else here would
           notice.

go run ./internal/release v0.1.0 [--dry-run | --push | --verify]

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL