incorrect release tags for go modules

[danielhochman]

Similar to #43 but did not want to try to revive a year old closed ticket. I also have some additional information on the problem and what I think is the solution.

Since go.mod is not at the root of the project, the required tag for the semver would be statsd/v3.2.1, whereas the current release tag is v3.2.1.

Each module has its own version information. Version tags for modules below the root of the repository must include the relative directory as a prefix. (source)

Additional Context

This is the error when trying to use v3 with go modules, which is looking for the missing tag statsd/v3.2.1.

reading github.com/cactus/go-statsd-client/statsd/statsd/go.mod at revision statsd/v3.2.1: unknown revision statsd/v3.2.1

[dropwhile]

That wiki page has been heavily edited over the years, so it is unsurprising that the recommendations have changed (Great updates at that link by the way. Thanks for sharing!). It seems the current layout does work for some people, likely accidentally (go.mod flagging it as +incompatible), but clearly doesn't work unsurprisingly nor uniformly.

Anyway... my main concern with changing how it currently works is the possibility of break something for some subset of projects that it does (mostly) work for right now. (sidebar: Maybe tagging with both methods would work? The linked wiki page seems to allude to that being workable. Still concerned about breakages for everyone else. 🤔).

A quick search though some of the dependent projects on pkg.go.dev seems to show that go.mod frequently flags it as +incompatible. This project started long before go.mod was a thing. If I had to do it over again, I would have just made it a top level thing instead. Alas...

Can you show a part of the go.mod for your project where it isn't working?
Do you think tagging with two tags would work, and if so, would it introduce breakages for folks already using the library?

[danielhochman]

I believe two tags will work fine since go modules just looks at the available tags. However, I don't have too much experience with glide to know the implications there.

What's weird to me about pkg.go.dev is that the latest is listed as v3.1.1+incompatible when 3.2.x has been up for almost a year. Not sure how it derives latest, and v3.1.1+incompatible also doesn't work at all for me.

We can test from a fork using a replace on the go modules side. Glide apparently has aliases that we can use to test from the fork as well.

The project this is for is https://github.com/lyft/clutch/blob/main/backend/go.mod, which is currently on a pseudo-version, want to move it to release versions. Noticed it originally because renovatebot is freaking out.

[dropwhile]

What's weird to me about pkg.go.dev is that the latest is listed as v3.1.1+incompatible when 3.2.x has been up for almost a year. Not sure how it derives latest, and v3.1.1+incompatible also doesn't work at all for me.

Yeah, agreed -- the pkg.go.dev version thing is pretty weird. go.mod version detection seems pretty funky on its own too.

We can test from a fork using a replace on the go modules side. Glide apparently has aliases that we can use to test from the fork as well.

I just tried to get it working for a while with a fork with two tags (vX.Y.Z, statsd/vX.Y.Z), one tag, go.mod at top level and in subdir, subdir only, top level only, and a few other permutations. The go.mod version detection seems incredibly strange, at the very least runs counter to what is described in the wiki. I would frequently get different versions detected (v1.0.2 detected after pushing v3.3.3 for example, or strange errors like "invalid: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3"), even when using GOPRIVATE (to avoid the go caching proxy). At least I'm not alone.

If you can find a solution that works, I'm willing to implement it.

[nrwiersma]

Your go.mod module must be suffixed with the version for version > 1. So it would be github.com/cactus/go-statsd-client/v3 and all imports would be github.com/cactus/go-statsd-client/v3/.... I will gladly open a PR to add Go mod if you like.