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.
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.
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:
But that doesn't parse:
go 1.0is weird, because we never called it that. Is that correct? Docs don't say.
go 1.1is 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.11for when modules were introduced?
/cc @ianlancetaylor @bcmills @jayconrod @dmitshur
The text was updated successfully, but these errors were encountered: