Open mooreds opened 3 years ago
I think this came up before via https://github.com/FusionAuth/go-client/pull/32
I'm not against it I suppose but I think there would be some work to do to make this work smoothly. We have a lot of build tools that check out by tag and we'd have to ensure we have exceptions in all of those tools to prefix this repo with a v
from whatever version we were to cut over.
Internal notes:
If we wanted to consider this change, it may be a change to the savant plugins as well as is
scripts, perhaps other places.
Thought I'd add my "I just hit this when attempting to pin to a specific version using go modules"
$ go get github.com/FusionAuth/go-client@v1.30.1
go: github.com/FusionAuth/go-client@v1.30.1: reading github.com/FusionAuth/go-client/go.mod at revision v1.30.1: unknown revision v1.30.1
$ go get github.com/FusionAuth/go-client@1.30.1
go get github.com/FusionAuth/go-client@1.30.1
go: github.com/FusionAuth/go-client@v1.30.1: reading github.com/FusionAuth/go-client/go.mod at revision v1.30.1: unknown revision v1.30.1
Using the savant release plugin, I see that this client library has releases (
1.29.0
,1.28.0
) and tags with the same format.However, the golang way is to preface the version with a
v
:v1.29.0
. This is documented here: https://blog.golang.org/publishing-go-modules and here: https://golang.org/doc/modules/version-numbersI reviewed the release git plugin ( http://savantbuild.org/docs/plugins/release-git/ ) but was unable to determine how to modify the build.savant file to prepend that
v
.This matters because when you pull in the lib as a go module, you are not able to pull in a specific version by tag. Instead, your
go.mod
file looks like:Discovered in the course of this: https://github.com/FusionAuth/fusionauth-site/pull/867