[BUG] Tag version with "v" prefix to make it work with go.mod about opensearch-go

[VijayanB]

Since most of go tools expects 'v' as prefix, i am favoring towards having all release tags to have 'v' as prefix. Instead of editing the existing tag, i am thinking about release new tag v1.0.0 and in future will have 'v' for all release tags. @dblock @henvic @stockholmux any objection?

[henvic]

Sure, @stockholmux!

From Go Modules Reference: Version:

A version identifies an immutable snapshot of a module, which may be either a release or a pre-release. Each version starts with the letter v, followed by a semantic version. See Semantic Versioning 2.0.0 for details on how versions are formatted, interpreted, and compared.

If I want to use this released version, I'd need to use Pseudo-versions. Reading the docs, I see:

Pseudo-versions never need to be typed by hand. Many commands accept a commit hash or a branch name and will translate it into a pseudo-version (or tagged version if available) automatically. For example:

go get -d example.com/mod@master
go list -m -json example.com/mod@abcd1234

This means I'd have to execute the following command to update my go.mod with version 1.0.0:

$ go get -d github.com/opensearch-project/[email protected]
go get: added github.com/opensearch-project/opensearch-go v0.0.0-20210831032935-8b5df4936baa

If we look what ends up in the go.mod file, it doesn't look good:

$ cat go.mod
module github.com/hatch-studio/customer-service/internal/dao/x

go 1.17

require github.com/opensearch-project/opensearch-go v0.0.0-20210831032935-8b5df4936baa // indirect

instead of containing the expected

require github.com/opensearch-project/opensearch-go v1.0.0

Now, if I want to know what version I'm using, I'd have to browse this repository and find 8b5df4936baa, which will show that it's tagged as 1.0.0.

I also wonder if it affects dependabot alerts in any way, but I don't think so.

[stockholmux]

OK - makes sense. So, there is no real friction at the time of adding the module but when trying to determine the module version later it's obscured.

It's a bit annoying that semantic versioning explicitly doesn't want the v but the official reference says to add it to semantic versioning. 🤦‍♂️

I think the bigger issue is any project wide tooling that is either in place or planned that will use things like a semver regexp. Let me dig.

[henvic]

Oh, also I see that if you go to Go's package search (https://pkg.go.dev/github.com/opensearch-project/opensearch-go) it shows no tagged/stable version.

[VijayanB]

Created new tag https://github.com/opensearch-project/opensearch-go/releases/tag/v1.0.0

[henvic]

Thanks!

$ go get -d github.com/opensearch-project/opensearch-go@latest
go get: upgraded github.com/opensearch-project/opensearch-go v0.0.0-20211002184036-fb1709a85d8d => v1.0.0

[stockholmux]

I'm a little mixed on this. All parts of OpenSearch uses semantic versioning that is X.Y.Z. Using vX.Y.Z introduces an inconsistency which makes my eye twitch. Seems like the linked context also has people with similar twitches.

I've only casually used golang, so can you help me understand the ramifications of using X.Y.Z with go mod? Feel free to chime in @VijayanB.

[henvic]

If you really want to keep using tags without the v prefix here, maybe you could get away using a vanity import (https://github.com/GoogleCloudPlatform/govanityurls), and have it tagged as v1.0.0 outside of the repository, but I've a feeling this complicates things (and maybe doesn't solve it completely somehow?).

[henvic]

I'd say there's some friction too for a set of users, though: whoever edits go.mod manually + run go mod tidy (what I usually do). I don't know what is the number of people that do this, though.

[henvic]

and latest version: Version: v0.0.0-...-fb1709a :|

[dblock]

Related, opensearch-project/.github#35

[dblock]

I think it's perfectly OK if opensearch-go tags with v if that's the convention of go rather than adopt convention of OpenSearch since this component doesn't release together with the complete distribution. It's the same in Ruby AFAIK.

[henvic]

Sounds good to me.

[kynrai]

This would be the best solution for golang users