Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/go: reject unenforced 'go' versions (older than 1.6) in 'go.mod' files #36319

Open
bradfitz opened this issue Dec 30, 2019 · 7 comments
Open

cmd/go: reject unenforced 'go' versions (older than 1.6) in 'go.mod' files #36319

bradfitz opened this issue Dec 30, 2019 · 7 comments
Labels
Documentation help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Backlog

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Dec 30, 2019 •
edited

If I have a very simple Go package that doesn't depend on any language features added since the original Go 1 release, I naturally thought I could put in my go.mod file:

go 1

But that doesn't parse:

$ go install
go: errors parsing go.mod:
/home/me/proj/go.mod:3: usage: go 1.23

But go 1.0 is weird, because we never called it that. Is that correct? Docs don't say.

go 1.1 is also weird, because it implies that I'm depending on something that was added in Go 1.1, but I'm not.

So I guess go 1.11 for when modules were introduced?

/cc @ianlancetaylor @bcmills @jayconrod @dmitshur
bradfitz added a commit to bradfitz/iter that referenced this issue Dec 30, 2019
@bradfitz
Add a go.mod file.
e8f45d3 
(It doesn't really depend on Go 1.11 but that's when modules were
added; see golang/go#36319)
@dmitshur
Copy link
Contributor

A related issue is #30791. Also see #30791 (comment) specifically.

@cagedmantis cagedmantis added this to the Backlog milestone Jan 2, 2020
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 2, 2020
@jayconrod
Copy link
Contributor

https://golang.org/cl/210799 should describe this in more detail.

go 1.11 makes sense to me: go.mod files didn't exist before that.

@bcmills
Copy link
Contributor

bcmills commented Jan 7, 2020

I believe that the compiler itself only cares about versions back to 1.8 anyway.

The compiler doesn't track features added before 1.9, so it can't enforce language changes from before that point. (There were non-trivial language changes in 1.1, 1.2, 1.4, and 1.5.)

@bcmills
Copy link
Contributor

bcmills commented Jan 7, 2020

In other words: we probably should not allow a go directive older than 1.6, since we don't actually enforce anything that far back.

@bcmills bcmills changed the title cmd/go: how to say Go 1 language version in go.mod file? cmd/go: reject unenforced 'go' versions (older than 1.6) in 'go.mod' files Jan 7, 2020
@bcmills bcmills added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels Jan 7, 2020
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 7, 2020
@josharian
Copy link
Contributor

It is worth noting that well-intentioned people like Brad or me may already have created go.mod files with older directives. (See e.g. josharian/intern@98cac2a. I picked that version because that was the version in which an optimization was introduced without which the package is useless.)

My 2c is that go 1 or go 1.0 would be the best magic markers for compatibility all the way back.

@bcmills
Copy link
Contributor

bcmills commented Jan 7, 2020

Perhaps rather than rejecting the older versions, we should upgrade them to 1.6 (and perhaps add a comment).

@bcmills
Copy link
Contributor

bcmills commented Jan 7, 2020

I don't think a marker for “compatibility all the way back” is a good idea unless it is actually enforced, and I don't think it's worth the labor to retrofit actual enforcement.

Without enforcement, the marker would give a false sense of confidence: once might expect that a package that successfully compiles with a go 1.0 directive would also compile with an actual Go 1 compiler, but that doesn't even remotely hold today.

@STRRL STRRL mentioned this issue Mar 4, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Documentation help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
7 participants
@bradfitz @josharian @cagedmantis @jayconrod @dmitshur @bcmills @gopherbot