I was reading a bit about best practices for go versioning and how it aligns to our release practices. To release a go module you simply tag the git repo with a "v" prefixed 3 segment version number. I noticed that Apache Arrow, which has a go module, use a "go/" prefix in front of their release number for go which i think i'd like to copy to make it clear why we have a tag with a naked version number and one with a "v" prefix (the official apache release for the former and the go convenience release for the latter).
Therefore for 3.5.3 we would have the official apache release tag as usual of "3.5.3" and the release tag for go of "go/3.5.3-rc1". Note that the "-rc1" suffix is our normal pattern for release candidates and it seems acceptable to the go ecosystem to use whatever suffix you like there. As we release 3.5.3 with 3.6.0 i would expected we'd also do "3.6.0" and "go/3.6.0-rc1" tags. As an aside, past release candidates don't seem to have bumped the pom at the version of the release so it remained in -SNAPSHOT. I assume we'd do the same here and tag at the commit prior to the pom bump to the actual release version. I do have some concerns about how strongly go documentation seems to like semver as our approach to semver is different than most. If any go experts care to share thoughts on any of what I've written here, it would be helpful.
