OK, so here's what I can see from the repo:
Current state: The repo is on v2 (the README says "This is version 2 of Quamina"), the latest release on GitHub is v2.0.0 (Jan 21, 2026), and all the source files are in the root directory — no /v2 subdirectory. The package quamina declarations across the .go files all use package quamina with no /v2 in the imports.
The problem is exactly what Marius described. The go.mod almost certainly still says:
module quamina.net/go/quamina
when it needs to say:
module quamina.net/go/quamina/v2
And that's why go get quamina.net/go/quamina@v2.0.1 spits out:
invalid version: module contains a go.mod file, so module path must match major version ("quamina.net/go/quamina/v2")
Here's the PR you'd want to put together (if you want to help Tim fix this):
-
go.mod— change the module line tomodule quamina.net/go/quamina/v2 -
All internal imports — grep for
"quamina.net/go/quamina"across the codebase and change them to"quamina.net/go/quamina/v2". Looking at the repo, this is actually a library with no internal sub-packages (everything ispackage quaminain the root), so there may be zero internal import paths to fix. That makes this way easier than most v2 migrations. -
Vanity domain — the
<meta name="go-import">tag atquamina.net/go/quamina/v2needs to resolve correctly. Since it's a vanity domain, Tim (or Lauren, who set it up) needs to make sure the redirect works for the/v2path too. Often this just works if the meta tag uses a prefix match, but it's worth verifying. -
Tag a new release — after merging, tag
v2.0.2(orv2.1.0or whatever) and create a GitHub release. The Go module proxy will then pick it up. -
Optionally — hit
https://proxy.golang.org/quamina.net/go/quamina/v2/@v/v2.0.2.infoto warm the proxy cache, or justgo getit.
The good news is that since this is a single-package library with no sub-packages, it's basically a two-line change (go.mod + maybe updating a go report card badge URL) plus the vanity domain check. Way less painful than most v2 migrations.