go install broken for v2.0.0 — go.mod module path missing /v2 suffix

[liropa]

Summary

The v2.0.0 tag ships a go.mod that still declares module github.com/kunchenguid/treehouse (no /v2). Go's semantic import versioning requires a module released at major version ≥ 2 to have its module path end in the matching /vN suffix. As a result, v2.0.0 cannot be installed with go install by any path, and @latest silently resolves to the old v1.8.0.

Reproduction (Go 1.2x, from an empty module)

$ go install github.com/kunchenguid/treehouse@v2.0.0
go: ...@v2.0.0: invalid version: module contains a go.mod file, so module
    path must match major version ("github.com/kunchenguid/treehouse/v2")

$ go install github.com/kunchenguid/treehouse/v2@v2.0.0
go: ...v2@v2.0.0: invalid version: go.mod has non-.../v2 module path
    "github.com/kunchenguid/treehouse" (and .../v2/go.mod does not exist) at revision v2.0.0

$ go list -m -versions github.com/kunchenguid/treehouse
github.com/kunchenguid/treehouse v1.0.0 ... v1.8.0        # v2.0.0 is absent

$ go list -m github.com/kunchenguid/treehouse@latest
github.com/kunchenguid/treehouse v1.8.0                    # @latest silently pins v1.8.0

Impact

• The README's documented install — go install github.com/kunchenguid/treehouse@latest — does not error; it silently installs v1.8.0. Users following the README never receive v2.x and get no signal that anything is wrong.
• Explicit @v2.0.0 and the /v2 path both hard-fail. There is no working go install for v2+.

Root cause

go.mod at tag v2.0.0:

module github.com/kunchenguid/treehouse   // must be .../v2 for a v2+ release

Suggested fix (standard major-version migration)

1. Set the module path to github.com/kunchenguid/treehouse/v2 in go.mod.
2. Update every internal import of github.com/kunchenguid/treehouse/... to .../v2/....
3. Update the README install command to go install github.com/kunchenguid/treehouse/v2@latest.
4. Re-tag (e.g. v2.0.1) from the corrected commit.

Refs: Module version numbering · Go Modules: v2 and Beyond

Workaround for users until a fixed tag ships

git clone --branch v2.0.0 --depth 1 https://github.com/kunchenguid/treehouse
cd treehouse && make build VERSION=v2.0.0
cp treehouse ~/.local/bin/     # or "$(go env GOBIN)"

[andrew-codes]

Confirming this is still present in later tags — reproduced the same failure on v2.1.1, the newest tag as of writing:

$ go install github.com/kunchenguid/treehouse@v2.1.1
go: ...@v2.1.1: invalid version: module contains a go.mod file, so module
    path must match major version ("github.com/kunchenguid/treehouse/v2")

$ go install github.com/kunchenguid/treehouse/v2@v2.1.1
go: ...v2@v2.1.1: github.com/kunchenguid/treehouse@v2.1.1: invalid version:
    module contains a go.mod file, so module path must match major version
    ("github.com/kunchenguid/treehouse/v2")

go.mod at v2.1.1 still declares module github.com/kunchenguid/treehouse (no /v2), same root cause as reported for v2.0.0. So every v2.x tag through at least v2.1.1 is affected, not just v2.0.0. go install github.com/kunchenguid/treehouse@v1.8.0 is the only tag that currently installs cleanly.

Would appreciate a fix + re-tag per the suggested steps above — happy to test once a corrected tag is out.

[mvanhorn]

Implemented in #87.

[kunchenguid]

Speaking as Kun's firstmate: #87 is still the fix for this. CI is not fully green (update-vendor-hash failed). We nudged the author. Leaving #62 open.

[kunchenguid]

Speaking as Kun's firstmate: still waiting on #87 (update-vendor-hash red). Leaving open.