cmd/go: should Go version be part of the go.mod specification?

[robpike]

If not, why not?

[neild]

A module may contain many packages, each of which may contain many files. Specifying the version in go.mod forces all packages and files within a module to use a consistent version.

I'm not sure if that's an argument for or against.

[dsnet]

Suppose the go.mod file specifies "go1.10", does that only mean the language as specified in Go1.10 or does that include other stuff?

A tangential question is whether the standard library will still be versioned along with the language specification? Clearly some packages like reflect must be versioned along with the language spec, but it's not clear to me that compress/flate must be versioned along with the language spec and compiler. Nor is this always desirable.

[spenczar]

I don't understand what benefit this would add over build tags. What would this be used for?

[ericlagergren]

Like @dsnet said, it depends what you mean.

From bug reports, I've noticed plenty of folks run older Go versions (> 1 version behind the current version) which causes issues when the package uses newer Go features. Build tags work, but things get hairy and you end up with little wrapper functions for the newer features—it all feels very un-Go-like. Personally, I've resorted to only supporting the most current Go version. But that isn't super user-friendly because sometimes they have legitimate reasons for staying on previous versions. It'd be nice to force things to be pinned to some minimum Go version, even if it's less than the current version.

[holygeek]

It should, but make it optional so that people are not forced to make a choice when they don't know better. Having Go version be part of go.mod would help give better error message and more importantly, save time for people who run "go get example.com/foo/bar" while running an older version of vgo-capable Go - "go get" can fail earlier rather than later.

[andrewchambers]

As a point of reference clojure leiningen specifies the language/stdlib version in the build tool.

[drewblas]

The go.mod has already implemented the concept of "This applies to my project, but dependencies can't introduce a restriction on my project" with the exclude command. The same could be applied here: A go-version command only applies to how my team builds our project. The go-version specified in any dependencies would be ignored.

[andrewchambers]

@drewblas there are packages that cannot be built with early go stdlibs, the only distinction between the stdlib/compiler and other libs is one is harder to fetch dynamically, conceptually they seem the same and the stdlib/compiler is just another minimal version dependency.

[jimmyfrasche]

Ignoring Go2 for a moment, there are three cases that I can think of for specifying a minimum version of Go

1. Relies on a language change introduced in that version
2. Relies on a package or func/type/etc introduced in that version
3. Relies on a behavior introduced in that version (For Go 1.10 this could be the funcs in bytes setting the cap or the change in runtime's os thread locking, for some examples)

(Aside: 1 and 2 could largely be determined mechanically, though the go version build tags would complicate that somewhat)

I don't see any point in distinguishing between these cases because they all come bundled together regardless.

In all of these cases, because of the compatibility guarantees of Go, it's not important which version of Go is used, as long as it's greater than or equal to the one specified. Unlike other requirements, if it's unspecified, it's implicitly Go 1.0.0.

If vgo sees that module X requires Go 1.15 but it's being run on Go 1.14 it would just have to stop and say "requires Go 1.15".

If you're trying to use a module, the build could just short circuit, let you know you need at least such and such version of Go, and save you some time.

If you're developing a module and making sure it works with newer versions of dependencies it could skip any that require newer versions of Go, let you know you need at least such and such version of Go to continue testing, and save you some time.

Having this could help with the transition to Go 2 because modules could explicitly declare that they're 2.0.0+ only.

I think it should be included but it would mean something different than other requires (perhaps it should have its own syntax to reflect this).

[spenczar]

I am still unsure what this would solve that isn't solved with build tags.

@jimmyfrasche, you listed three cases: language changes, new objects, and behavior changes.

In the first two cases, the code will not compile. vgo doesn't need to warn you that the code won't compile. That information would be redundant.

In the third case, build tags would allow a package to require a particular version. If lower versions need to be forbidden, that can be accomplished with tagged file that deliberately fails to compile:

//+build !go1.10

package foo

// If you are seeing a compiler error here, please upgrade to Go 1.10 before
// using foo. It relies on the changes to Barbaz introduced in that version.
This package requires go1.10.

---

To my eyes, the only benefit is that it would preempt a compiler error with a more descriptive error message if an imported package relied upon newer Go features. Is that all?

[jimmyfrasche]

@spenczar

To my eyes, the only benefit is that it would preempt a compiler error with a more descriptive error message if an imported package relied upon newer Go features. Is that all?

Yes, but that's not nothing. The benefit of having it in one well defined place is good for humans and computers.

If you're looking a module you can see at a glance what the requirements are (and vgo could compute the transitive requirements so that even if all your code only requires Go 1.5+ but something you import requires Go 1.15+ it would list Go 1.15).

Also, imagine it's 10 years from now and for whatever reason you're stuck with Go 2.1.3 at work. You need a package for Oauth4 so you search for it on godoc.org. There are many results but you're going to have to download them one by one just to see if they compile. If the minimum transitive Go version is part of the machine-readable module specification, godoc.org could let you include that constraint in the search and filter out the results that definitely won't work.

[jimmyfrasche]

Also writing "require go 1.11" or what have you is just a lot easier than making a file like that so it's more likely people will document the constraint, especially if there's a tool that automatically derives it in cases 1 and 2 so they'd only ever need to think about it in case 3.