chore: set up go modules

[MCBrandenburg]

This will set up the go.mod file for this repo to use Go Modules.

[MCBrandenburg]

I updated the build.savant file to include the v in front of the version tag so they will look cleaner in the go.mod files for projects that use this package.

module github.com/MCBrandenburg/test

go 1.14

require github.com/FusionAuth/go-client v.1.8.4

versus

module github.com/MCBrandenburg/test

go 1.14

require github.com/FusionAuth/go-client v0.0.0-20200722035946-d7472ac378ca

[robotdan]

Can we accomplish this without a change to build.savant ?

[MCBrandenburg]

@robotdan Go expects the git tag to be in the form of v{major}.{minor}.{patch}. Is there something else that can be done to tag it in this form?

[robotdan]

Perhaps, I'll have to look at it. We versioning and tagging is all automated by our build tools.

[MCBrandenburg]

@robotdan removed the changes to build.savant

[robotdan]

For clarify on my end, the go.mod file only indicates that the project is depending upon Go version 1.14?

And unless we modify our tag name to be v{major}.{minor}.{patch} then when you include this module, you have to reference it using the Pseudo version https://golang.org/cmd/go/#hdr-Pseudo_versions. Is that correct?

I'm hesitant to change the way we tag this repo. We use Semantic Versioning 2.0.0 across all of our projects which does not require a v prefix. https://semver.org/ As far as I can tell the v prefix is a hold over from SemVer v1.

It looks like there is still some debate perhaps, or other suggestions that Go support both vX.Y.Z and X.Y.Z.
golang/go#24007 (comment)

I'm happy to accept the go.mod if that helps and if you want to open a separate issue regarding the tag prefix we can review the go modules spec a bit closer.

[MCBrandenburg]

The go mod would show dependencies outside of the standard library, but there aren't any in this package.

The problem with the current pseudo version is that it is tied to the commit hash and doesn't show a version, so if a user wanted to go to 1.8.6 to 1.8.7 they wouldn't have an easy way of doing it.

The debate you mentioned is from 2018, and a comment on a more recent ones golang/go#32945 (comment) golang/go#30146 (comment) make it seem like there is no chance of this being done.

I would like to get this merged in but this wouldn't be necessary since consumers of the package wouldn't be able to cleanly hop from one version to the another.

Would tagging vx.y.z as a part of the process(leaving your tags of x.y.z in) be possible

[MCBrandenburg]

@robotdan any thoughts on my suggestion that we could tag this repo both ways? vX.Y.Z & X.Y.Z? It would make understanding what version I'm developing against easier to ascertain

[drpebcak]

Would definitely be useful to version the go client in a way that is useful for go.