Gitaly module version cannot be updated in gitlab-workhorse and gitlab-shell
On a clean Go v1.15.2 installation, I get this while trying to update the Gitaly module in gitlab-workhorse and gitlab-shell:
$ go get -u gitlab.com/gitlab-org/gitaly@v13.5.0-rc1
go: downloading gitlab.com/gitlab-org/gitaly v0.0.0-20201001041716-3f5e218def93
go: gitlab.com/gitlab-org/gitaly v13.5.0-rc1 => v0.0.0-20201001041716-3f5e218def93
cat go.mod
go get: inconsistent versions:
gitlab.com/gitlab-org/gitaly@v0.0.0-20201001041716-3f5e218def93 from gitlab.com/gitlab-org/gitaly@v13.5.0-rc1 requires gitlab.com/gitlab-org/gitaly@v1.68.0 (not gitlab.com/gitlab-org/gitaly@v0.0.0-20201001041716-3f5e218def93 from gitlab.com/gitlab-org/gitaly@v13.5.0-rc1)
According to https://github.com/golang/go/issues/35732 and https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning, this is because Go is trying to enforce semantic compatibility:
In semantic versioning, changing the major version number indicates a lack of backwards compatibility with earlier versions. To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2, and packages in that module would use that path as their import path prefix, as in example.com/m/v2/sub/pkg. Including the major version number in the module path and import paths in this way is called "semantic import versioning". Pseudo-versions for modules with major version v2 and later begin with that major version instead of v0, as in v2.0.0-20180326061214-4fc5987536ef.
I think this is saying that Gitaly should be using m/v13
in the module path.
A workaround may be to tag another v1 tag with the latest master:
Code written before the semantic import versioning convention was introduced may use major versions v2 and later to describe the same set of unversioned import paths as used in v0 and v1. To accommodate such code, if a source code repository has a v2.0.0 or later tag for a file tree with no go.mod, the version is considered to be part of the v1 module's available versions and is given an +incompatible suffix when converted to a module version, as in v2.0.0+incompatible. The +incompatible tag is also applied to pseudo-versions derived from such versions, as in v2.0.1-0.yyyymmddhhmmss-abcdefabcdef+incompatible.
v1.87.0 was tagged in February 2020, and then we switched versioning schemes.
@pokstad1 @samihiltunen What do you think we should do here?