v2 release is unusable: go.mod module path missing /v2 suffix

Summary

The v2 release of gitlab.com/gitlab-org/api/client-go cannot be consumed by Go projects. The go.mod module path does not include the required /v2 suffix, causing the Go toolchain to reject any attempt to go get the v2 tags.

Steps to reproduce

$ go get gitlab.com/gitlab-org/api/client-go@v2.2.0
go: gitlab.com/gitlab-org/api/client-go@v2.2.0: invalid version: module contains a go.mod file, so module path must match major version ("gitlab.com/gitlab-org/api/client-go/v2")

$ go get gitlab.com/gitlab-org/api/client-go/v2@v2.2.0
go: gitlab.com/gitlab-org/api/client-go@v2.2.0: invalid version: module contains a go.mod file, so module path must match major version ("gitlab.com/gitlab-org/api/client-go/v2")

Root cause

Per the Go Modules v2 and Beyond documentation, any module at major version v2 or higher must declare a module path with the corresponding major version suffix. The go.mod module directive must read:

module gitlab.com/gitlab-org/api/client-go/v2

Additionally, all internal import paths within the module need to be updated to use the /v2 suffix.

Currently the go.mod still declares:

module gitlab.com/gitlab-org/api/client-go

which is only valid for v0/v1 releases.

Impact

No consumer can adopt v2 of this library. The module is effectively broken for the Go ecosystem until this is resolved.

Options for resolution

There are two standard approaches documented by the Go team:

Option A — Major version subdirectory (recommended by Go team)

Keep the v1 code at the repository root and introduce a v2/ subdirectory with its own go.mod declaring module gitlab.com/gitlab-org/api/client-go/v2. This allows v1 and v2 to coexist in the same repo and is the most broadly compatible approach.

/go.mod    → module gitlab.com/gitlab-org/api/client-go       (v1)
/v2/go.mod → module gitlab.com/gitlab-org/api/client-go/v2    (v2)

Option B — Major version branch + fix go.mod in place

Update the go.mod on the current branch/tag to declare module gitlab.com/gitlab-org/api/client-go/v2 and update all internal imports accordingly. Re-tag or release a patch (e.g. v2.2.1) with the corrected go.mod. v1 would live on a separate v1 branch.

Recommendation

Both Option A and B are well-precedented. I'd lean toward Option B: it avoids duplicating large swaths of code, and given that we don't intend to maintain two major versions in parallel, the subdirectory approach offers little benefit over a clean branch split.