DECISION: canonical Go module path for 1.0 #79

New Issue

clawbot · 2026-08-09T03:43:25+02:00

clawbot commented

2026-08-09 03:43:25 +02:00

Owner decision required. Blocks the 1.0 tag and the README install
instructions (#75).

The conflict

go.mod:1 — module sneak.berlin/go/mfer
mfer/mf.proto:3 — option go_package = "git.eeqj.de/sneak/mfer/mfer";

These disagree. Once 1.0 is tagged the module path is effectively permanent:
changing it later is a breaking change for every importer and requires a
major-version bump under Go's import compatibility rule.

Options

A. sneak.berlin/go/mfer (recommended). Matches the repo policy — "Go
module root: sneak.berlin/go/<name>" — and matches what go.mod already
says, so no code changes beyond the proto. It is a vanity path, which
decouples the import path from where the code is hosted; the repo can move
without breaking importers. Requires that sneak.berlin/go/mfer serve a
go-import meta tag, which needs to be verified as actually working before
the tag.

B. git.eeqj.de/sneak/mfer. Matches where the code actually lives and
needs no vanity-import hosting. But it contradicts the stated policy, and it
welds the import path to the current Gitea instance.

The proto's current value is a third thing again — git.eeqj.de/sneak/mfer/mfer
— which is neither of the above as a module root.

Recommendation

Option A. It is what policy mandates and what go.mod already declares; the
proto is simply wrong and should be corrected to match. The one real risk is
the vanity redirect not being served — that is worth verifying now rather
than discovering it at tag time.

Definition of done, once answered

go.mod and mfer/mf.proto go_package agree.
mfer/mf.pb.go is regenerated from the corrected proto and committed.
If option A: go install sneak.berlin/go/mfer/cmd/mfer@latest is verified
to actually resolve from a clean module cache. If it does not, the vanity
redirect must be fixed before 1.0, and that becomes a blocking sub-task.
All import paths in the repo are consistent.
README install instructions use the decided path (#75).
make check passes and docker build . succeeds.

Please answer inline and reassign to clawbot to implement.

Owner decision required. Blocks the 1.0 tag and the README install instructions (#75). ## The conflict - `go.mod:1` — `module sneak.berlin/go/mfer` - `mfer/mf.proto:3` — `option go_package = "git.eeqj.de/sneak/mfer/mfer";` These disagree. Once 1.0 is tagged the module path is effectively permanent: changing it later is a breaking change for every importer and requires a major-version bump under Go's import compatibility rule. ## Options **A. `sneak.berlin/go/mfer` (recommended).** Matches the repo policy — "Go module root: `sneak.berlin/go/<name>`" — and matches what `go.mod` already says, so no code changes beyond the proto. It is a vanity path, which decouples the import path from where the code is hosted; the repo can move without breaking importers. Requires that `sneak.berlin/go/mfer` serve a `go-import` meta tag, which needs to be verified as actually working before the tag. **B. `git.eeqj.de/sneak/mfer`.** Matches where the code actually lives and needs no vanity-import hosting. But it contradicts the stated policy, and it welds the import path to the current Gitea instance. The proto's current value is a third thing again — `git.eeqj.de/sneak/mfer/mfer` — which is neither of the above as a module root. ## Recommendation Option A. It is what policy mandates and what `go.mod` already declares; the proto is simply wrong and should be corrected to match. The one real risk is the vanity redirect not being served — that is worth verifying now rather than discovering it at tag time. ## Definition of done, once answered - `go.mod` and `mfer/mf.proto` `go_package` agree. - `mfer/mf.pb.go` is regenerated from the corrected proto and committed. - If option A: `go install sneak.berlin/go/mfer/cmd/mfer@latest` is verified to actually resolve from a clean module cache. If it does not, the vanity redirect must be fixed before 1.0, and that becomes a blocking sub-task. - All import paths in the repo are consistent. - README install instructions use the decided path (#75). - `make check` passes and `docker build .` succeeds. Please answer inline and reassign to `clawbot` to implement.

clawbot added this to the 1.0.0 milestone 2026-08-09 03:43:25 +02:00

sneak was assigned by clawbot

2026-08-09 03:43:25 +02:00

clawbot referenced this issue

2026-08-09 03:43:38 +02:00

Release mechanics for v1.0.0: version single-sourcing and tag #80

clawbot referenced this issue

2026-08-09 03:44:35 +02:00

DECISION: public API surface and determinism defaults for 1.0 #83

Sign in to join this conversation.