Make the release tags version go mod compatible.

[deepanshutr]

It would be great to have the tagged release be named in the format vX.X.X format so that go mod can read it. Else the mod file shows something like github.com/asaskevich/govalidator v0.0.0-20200108200545-475eaeb16496 which is not very readable and difficult to upgrade.

[xmlking]

	github.com/asaskevich/govalidator v0.0.0-20200428143746-21a406dcc535

is hard to verify which version is in use

[xmlking]

any plans to adopt go mods do Semantic Versioning ?
I can help with PR if the maintainers are interested.
Thanks

[yhrn]

@xmlking Wouldn't this just require a creating a new GitHub release using the correct semver format?

Or are you thinking about adding the major version to the module path? Because this repo hasn't used semver before it's a bit unclear to me what the first semver should be. If existing versions have been backwards compatible then maybe they should be seen as minor versions, e.g. v11 would correspond to v0.11.0, and in that case the first semver compatible version could be v0.12.0 and the module path could stay as it is.

On the other hand if v11 should be seen as corresponding to v11.0.0 then /v12 should probably be added to the module path when creating a v12.0.0 release.

[xmlking]

Right, all we have to do is create a git tag and push to default branch. I think v11.0.0 could be our first tag
Ref https://blog.golang.org/go116-module-changes

[xmlking]

Unless we have breaking change in next release, we don’t have to tag next version as v12.0.0.
Next version could be v11.1.0 or v11.0.1

[yhrn]

What I am referring to is this.

For a repo that has been following SemVer before and is on v2+ but is not using Go Modules the recommendation for when adopting it is clear as per this. The gist of it is that the module already being on v2+ implies that there have been breaking changes in the past which is not allowed according to the import compatibility rule so then the import path should be appended with the major version.

However, because this repo has not been following SemVer before it is not as obvious if each new release should be seen as a new major version or not. I don't know if there has ever been any breaking changes between releases but even if there hasn't it might be less confusing to start at v11.1.0 or v12.0.0. If we do that then I do believe that to follow best practices the import path should be suffixed with the major version, which in turn would point to v12 this change in itself is breaking.

We could of course say that this is all a bit unnecessarily strict and just create a v11.0.0 release from exactly the same commit as v11, or maybe a v11.0.1/v11.1.0 release from HEAD (not sure how significant the latest commits are) and be done with it.

[migueleliasweb]

What I am referring to is this.

For a repo that has been following SemVer before and is on v2+ but is not using Go Modules the recommendation for when adopting it is clear as per this. The gist of it is that the module already being on v2+ implies that there have been breaking changes in the past which is not allowed according to the import compatibility rule so then the import path should be appended with the major version.

However, because this repo has not been following SemVer before it is not as obvious if each new release should be seen as a new major version or not. I don't know if there has ever been any breaking changes between releases but even if there hasn't it might be less confusing to start at v11.1.0 or v12.0.0. If we do that then I do believe that to follow best practices the import path should be suffixed with the major version, which in turn would point to v12 this change in itself is breaking.

We could of course say that this is all a bit unnecessarily strict and just create a v11.0.0 release from exactly the same commit as v11, or maybe a v11.0.1/v11.1.0 release from HEAD (not sure how significant the latest commits are) and be done with it.

The last option seems far too easy to not implement. Just tag v11.0.0 and we're golden! 🙏

[yhrn]

@asaskevich How would you feel about just tagging the current release v11 with v11.0.0?

And then from now on releasing v11.x.y until there are breaking changes?

[asaskevich]

@yhrn @xmlking @migueleliasweb @deepanshutr that sounds good. I've created v11.0.0 tags so you can check if everything is fine

[jerome-laforge]

It seems it is not fine as I always have to import like this:

require (
   github.com/asaskevich/govalidator v0.0.0-20210307081110-f21760c49a8d
)

Maybe you have to respect the SIV

If I force v11.0.1, I have this error:

go.mod:6:2: require github.com/asaskevich/govalidator: reading https://proxy.golang.org/github.com/asaskevich/govalidator/@v/v11.0.1.info: 410 Gone
        server response: not found: github.com/asaskevich/govalidator@v11.0.1: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v11

[yhrn]

Yeah, it seems like the module path needs to be changed to github.com/asaskevich/govalidator/v11 for that to work then.

Another option that might work is to treat the old, non-semver releases (v1, ..., v11) as minor versions and tag the latest version with v0.11.0 instead (could be v1.11.0 as well but I think that might be easier to confuse with the old versions)

[kolaente]

The missing /v11 suffix makes this module unusable in go mod projects when using v11:

$ GOPROXY=direct go get -u github.com/asaskevich/govalidator
go: github.com/asaskevich/govalidator/v11@v11.0.1: go.mod has non-.../v11 module path "github.com/asaskevich/govalidator" (and .../v11/go.mod does not exist) at revision v11.0.1

Any way to add this?

[nightah]

@asaskevich we had a similar issue in our project which needed to be resolved by including the major version in the import path per @yhrn's commentary above.

Effectively once the major version is in the import path you can release v11.0.2 and it will fix your tagging issues.

As previously mentioned too if the major version gets bumped you should also be incrementing that in your import path to be in line with semver releases for the go.mod.

Would you be happy to accept a PR which fixes this issue?

[sergeyglazyrindev]

Hello guys!
I forked this package cause owner disappeared. Hope, he will be back, but it would be easier to merge these changes back if he is back
Link to my repo: create issue there and we'll discuss it.