Please also include /v0 in this list

I'll take a stab if there's no objection; I'll try to find a way which minimizes the changes needed to CreateModFile and introduce a test.

Do you think there's any other 'special' rules we should take care of, or just disallow the /v0 and /v1 suffixes?

The rules are https://golang.org/ref/mod#go-mod-file-ident

It currently also doesn't reject leading or trailing ., you'll have to check the others

Let's limit a fix to just the major version suffix.

There are lots of local modules that just have a single element path or don't have a dot in the first element. These modules can't be fetched normally, but they can appear on the left side of a replace directive. That should keep working.

Technically, we could say this is working as intended, but that seems user hostile. Someone who names their module m won't expect that to work with go get. But someone who names their module github.com/foo/bar/v1 might expect that to work without a replacement.

cc @bcmills @matloob

Change https://golang.org/cl/288712 mentions this issue: cmd/go: make mod init disallow invalid major version suffixes

I've opened a CL which utilizes module.SplitPathVersion to enforce the rules in place for the major version suffix.
I hope I got this right, let me know if I missed anything obvious.

One more point, and I'm not sure I'm reading this correctly is that the 'Module paths and versions' documentation could be improved.

Right now, I think it's a little contradicting on whether dots are allowed in /vN-like suffixes (first mentions that can be used and then that cannot). But I should probably open a new issue for that one.

For a final path element of the form /vN where N looks numeric (ASCII digits and dots), N must not begin with a leading zero, must not be /v1, and must not contain any dots.

@tpaschalis Why gopkg.in is in the CL?

@seankhliao Are negative numbers allowed?

Hello @inet56, thanks for reaching out. The documentation defines the valid major version suffixes, for gopkg.in and non-gopkg.in module paths. These checks are implemented in modules.SplitPathVersion. The CL provides a helpful error message for both cases. Do you think it makes sense?

Also, I don't think that a negative version would make sense in a versioning system.

Why is gopkg.in treated specially?

Also, I don't think that a negative version would make sense in a versioning system.

What will happen if someone run

go mod init example.com/foo/v-1

I think the reason why gopkg.in is treated in a special way is mainly compatibility. The major version suffixes and the import compatibility rule were already in place at gopkg.in before Go modules came along. I feel this goes well in hand with Go's compatibility promise, and not breaking users' workflow.

Regarding the go mod init example.com/foo/v-1 example, I think it should create a module named example.com/foo/v-1 with no version suffix.

My 2c from the docs and gut feeling that v-1000 is a valid module path element (eg. a username, repo name, or URL path), and is not easily mistaken for a version suffix so that it's explicitly disallowed, but someone more experienced could chime in.

@inet56 please refer to:

• https://tip.golang.org/ref/mod#versions
• https://semver.org/spec/v2.0.0.html
• https://tip.golang.org/ref/mod#major-version-suffixes