Changing the version tag format or consider an additional tag for each release

[harikb]

This request is regarding this particular issue with how the way we format the release version affects the Go bindings
#3338 (comment)

I believe the issue can be solved by tagging the release as, say , v6.2.30 instead of 6.2.30 - an extra letter v before the version number. This will allow go modules to understand the version as really 6.2.30 instead of assuming it as 0.0.0 . I believe this is also the default format in github.

Tagging suggestions
It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4

If the change would break some other fdb build/release process, would you be open to addition an additional `vM.m.p' tag for each release? This may also be the easiest way to test if this would fix the issue.

Thanks

--

Hari

[harikb]

FYI - I am discussing it here https://gophers.slack.com/archives/C9BMAAFFB/p1614874053239900 in the #modules channel in Gopher slack. I was wrong about the format above. Their recommendation seems to be (from the discussion so far)

1. Start adding bindings/go/vX.Y.Z as version tag
2. Recommend users to import them as import "github.com/apple/foundationdb/bindings/go/src/fdb/v6"

Anyone who doesn't switch to this format will continue to stay at whichever version they originally downloaded. On this last point, is that the expected behavior? Even in your current model, you expect them to run that ./fdb-go-install.sh install --fdbver <x.y.z> script, so automatic upgrade to minor/patch version is not expected ( unless someone manually runs that script again ). Am I correct in the assumptions that I am making?

[harikb]

Let me also link another ticker here golang/go#26964

[ammolitor]

I am re-working our current release pipeline, I'll add this to the list of things to consider.

[ammolitor]

This issue is more than a year old. I can create other tags if it's helpful, but it's not clear to me if that is the necessary solution.