I don't see anything "Go 2" about this proposal. It's not a language or library change, and could presumably take effect immediately. Any reason to keep the Go2 label here?

I love this proposal. I happened to have a problem with the runtime.Version today. So the naming of the Go versions caught my attention too. A huge thanks to you @dmitshur. 😁

However, I think we also need to pay attention to the Go versions without tags. According to the comment of the runtime.Version:

Version returns the Go tree's version string. It is either the commit hash and date at the time of the build or, when possible, a release tag like "go1.3".

The "commit hash" will disrupt the new naming rules you proposed. So, I think we can use some credits of Go modules. We can rename the original "commit hash" to "v0.0.0-20060102150405-0123456789ab". Then we can do something like semver.Compare(runtime.Version(), "v1.13.0").

could presumably take effect immediately

Do you mean retroactively changing all previous releases to start using a new version scheme, or to start using it for new releases only?

I proposed this for Go 2 in the sense we can consider starting to do this as of Go v2.0.0 release. I didn't think it was possible to retroactively change previous releases, and mixing-and-matching different versioning schemes within v1.x.x releases didn't seem great either.

However, we can consider those options too. In that case, the Go 2 label isn't necessary.

Edit: As @aofei mentioned, there are additional considerations such as output from runtime.Version, build constraints, etc.

As discussed at https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md, it is, I think, unlikely that there will ever be a Go v2.0.0 release. But if you want to wait for that in case it happens, that is OK with me, in which case we should put this proposal on hold for now.

I think keeping it targeted at Go 2 and putting on hold for now is okay.

I wanted to write up this initial proposal to have a proposal to reference and gather initial feedback. For now, it can continue to target a hypothetical v2.0.0 release. I can take the time to flesh out the details and see what would it take to implement this concretely in an earlier v1.x.x release, and then we can re-consider it for that.

Wait until v2.0.0 to adopt this proposal? lol 😂

I agree with @ianlancetaylor, there should be no "Go2". If this proposal is to be adopted, then it should take effect immediately. In fact, I think we should have done this long ago. I mean this proposal should be proposed along with the Go modules proposal. Unfortunately, it does not. Why is Go urging everyone to strictly follow the semver, but Go itself doesn't do it? This should not happen.

See #27255.

Thanks for pointing out #27255 to me. I hadn't found it when I was doing a search to see if this was proposed in the past. It covers an important subset of this proposal, so I plan to read through it and take the information there into account.

It would be a service to the community at large to have Go's module system use the strict semver model (https://semver.org/), which is three numeric fields separated by periods, followed by optional prerelease and build tags. There should always be 3 numbers and the 'v' prefix is spurious.

The argument for rejection in #27255 was, in essence, it's only us so it doesn't matter. But Go is part of a larger world and there are tools that work across languages. Also, large systems often contain many languages and consistency across their handling eases development. It would be better to lead by following the proposed standard than to stick to the unique form it has now.

We have a lovely consistent set of versions dating all the way back to Go 1. If we change the way Go version strings are written then anything that consumes such strings needs to consume both the old format and the new one. Or am I missing something?

@adg I didn't include a section talking about the costs of implementing this proposal; perhaps I should have. You're absolutely right, that is one of the disadvantages of changing the version format.

I can think of some ways of dealing with it:

1. At some point long long in the future, v1.x.x versions may become very old and less actively looked at by most users. This is similar to how today, versions before the initial go1 release are rarely looked at in practice. It's still important to keep them for historical reasons, but I doubt tags like release.r57.1 or weekly.2012-01-27 see much use, so it's more okay that they use a different format.

2. If we limit the scope of this proposal to tags, then perhaps we can retroactively apply semver tags to all previous go1.x.x releases. That would be backwards compatible because all old tags would stay around. However, new users and tools can choose to start using semver tags and would only need to parse/handle those to have support for all versions of Go from v1.0.0 until the most recent version.

I found these for you @robpike, and I think their discussions may be helpful in determining whether there should be a "v" prefix: semver/semver#204 semver/semver#235 especially semver/semver#424 (comment)

And BTW, semver itself is using the "v" prefix. See https://github.com/semver/semver/releases.

After all, I think it's okay to use v1.0.0, go1.0.0 or even Go v1.0.0 (definitely not), just having their main parts strictly follow the semver is enough. Seems that the v1.0.0 style is more friendly and acceptable, since the Go modules has already rolled it out (https://github.com/golang/go/wiki/Modules#semantic-import-versioning).

What @rsc mentioned in #27255 (comment) seems that he sees this kind of changes as incompatible. I don't know, maybe. For me, I can only find one incompatible change at the moment, which is the output style of the runtime.Version. But I don't think it is enough to be an obstacle. If someone is really dependent on the output of the existing runtime.Version, then I think we can add a new func, such as runtime.Semver, perhaps.

Edit: In my opinion, implementing this new Go version naming convention from v1.13.0 will be very flattering, since v1.13.0 will bring huge enhancements to the Go modules.

We have a lovely consistent set of versions dating all the way back to Go 1. If we change the way Go version strings are written then anything that consumes such strings needs to consume both the old format and the new one. Or am I missing something?

Whoever (edit: to clarify: distributors, packagers, etc) has an update mechanism for Go in place today, will be able to make a small change by saying "this range follows what we previously defined for Go" and "everything else follows semantic versioning".

@ng-0 yes, precisely my point.

There would be some advantages to having the Go tool itself following semver, but I would be OK if that doesn't happen, including because there are a different set of goals, constraints and possible mistakes that are in play for versioning an API or program (which is arguably what semver is most targeting), vs. versioning a programming language.

As I understand it, there is an option and likely plan to introduce breaking changes without incrementing the 1 for Go, but to do so carefully, and without redefining the meaning of any current programs, and while still allowing for example the removal of capabilities. For example, from the "Go 2 transition" proposal

I think the only feasible safe approach is to not permit language redefinitions.

and

For example, for issue #20733, the range issue, we could change range loops so that taking the address of a range parameter, or referring to it from a function literal, is forbidden. This would not be a redefinition; it would be a removal.

Perhaps one could argue that the go version directive in go.mod is a way of preserving backwards compatibility and hence perhaps one could argue that even if Go was to be under semver then those types of changes could happen without incrementing the major version of 1 for Go? However, the future semantics of the go version directive in go.mod seems to be a matter of some discussion or at least not widely understood yet (#30791), so I should probably not rely too much on my own understanding of how that might work.

That said, a narrower version of this proposal would be to always have the last dot for any future initial major release, such as go1.14.0 rather than go1.14.

Of all the flavors of version strings @dmitshur listed in his opening comment, I think versions like go1.12 and go1.13 are the most unnecessarily confusing and ambiguous. (I am ignoring go1 for now as a historical artifact).

@bcmills wrote in #29984 (comment):

Personally, I think it's pretty confusing to have the first patch version in the 1.11 line be named go1.11 rather than go1.11.0, especially given that go get some/module@1.11 in module mode does mean “the latest patch release of some/module with minor version 1.11”. The lack of minor-version on the first release buries a major clue to the user that there might be more recent versions available.

I would like to see us release Go 1.12 as go1.12.0 instead of go1.12.

@mvdan wrote:

I too have wished for 1.11 to be 1.11.0 for a while. Too many users think they're running the latest 1.11 because they're on 1.11. "What do you mean the latest 1.11? I am on 1.11"

@dmitshur, I am guessing you would view that as a completely separate proposal rather than a variation of your current proposal, but wanted to at least mention it, including it could be viewed as a smaller but useful step towards your proposal.

@thepudds Thanks for surfacing that information, it's helpful to see that more people have voiced a desire for the ".0" suffixes to not be omitted.

I am guessing you would view that as a completely separate proposal rather than a variation of your current proposal

This proposal does not have a very specific implementation plan attached to it yet, and so I view a proposal to include trailing zero version components as closely related to this proposal.

To repeat and summarize my proposal at a high level, it is "use semver for Go release versions". The three benefits I'm looking to achieve are:

1. Eliminate confusion/ambiguity about meaning of "go1.12" by always including zero version components, i.e., use "go1.12.0".
2. Eliminate confusion/ambiguity about meaning of "minor version" by using semver notation to refer to version components (i.e., in goX.Y.Z, X should be called "major", Y "minor", and Z "patch").
3. Eliminate use of two different version schemes (semver for module versions, Go's own notation for Go releases).

To me, both 1 and 2 are very important goals. 3 is nice but much less important.

As a result, a proposal/solution that resolves 1 would be a great win to me.

However, I suspect the cost of making any change, regardless of how small or trivial, to the version scheme used by Go releases is quite high. As a result, if we're going to change it from just go "go1.12" -> "go1.12.0", then I suspect the additional cost of changing prefix from "go" to "v" and doing the minor "beta1" -> "-beta.1" change to make it fully semver compliant would be relatively small that it'd be better to do it all at once rather than not.

This is why I framed this proposal about moving completely to semver, rather than a smaller "go1.12" -> "go1.12.0" change.

Change https://golang.org/cl/229481 mentions this issue: internal/history: rename Version to GoVer

One way of dealing with this, regardless of whether the Go project does switch to semver or not, would be to provide a simple utility function that translates from a Go version (e.g. go1.15beta1) to a semver equivalent (v1.15.0-beta.1). The mapping is well defined as @adg pointed out. Such a function could live in golang.org/x/mod/semver

At some point between filing this proposal and now, I've realized that the "v" part in a string like "v1.2.3" is not a part of SemVer 2.0.0. See https://semver.org/spec/v2.0.0.html#is-v123-a-semantic-version. So any semver parser would only see the "1.2.3" substring. That means there's no good reason to change the "go" prefix to "v". I think keeping "go" prefix is a good idea, I withdraw the suggestion to change that.

I've updated this detail in the original proposal for better visibility. (I would've done this much earlier, but this proposal was on Hold so I left it for later. But it's more relevant now given discussion in #57631.)

I just wrote a lot of new version code for the GOTOOLCHAIN work (#57001). The extra zero digit on major releases turned out to be a great help - if we hadn't already accepted #57631 we'd have had to add it anyway, so thanks to @thepudds for anticipating that. The extra zero digit helps because it solves a real problem: distinguishing between the Go 1.21 language definition + release family and the Go 1.21.0 release. In contrast, changing to semver does not solve a problem. It just changes syntax in a way that people have to learn. Yes, it would use a semi-standard syntax, but it would still be our own defined subset of Semver, not complete Semver. That would be significant churn without significant benefit.

When I first started working on the GOTOOLCHAIN code, I handled Go versions in MVS by defining conversion functions from Go version syntax -> Semver and then Semver -> Go version syntax. That was pretty tricky and annoying, and it was difficult to catch all the places where the "internal" Semver form might leak out. @bcmills pointed out to me that the MVS library did not assume Semver at all, and that by making a minor adjustment I could let it operate directly on the Go version syntax. That was an enormous simplification and cleaned up tons of rough edges. We could in theory switch from Go versions to semver, but:

1. We'd still have to support the go syntax for all the old versions.
2. We'd have to teach people the new rc syntax and then have to explain to people why some versions are "1.21rc2" while others are "1.22.0-rc.1" or whatever we decide on.
3. We'd have to invent some stand-in for the concept of the language version (1.21 as different from 1.21.0).

The code is written and everyone understands the current syntax. Most importantly, the GOTOOLCHAIN code understands the current syntax. If we switched to semver in the future, that would invalidate all the old toolchains being used perfectly well to run newer versions of Go. At this point I think the ship has sailed, and the island it landed on is Go's version syntax, not semver.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

It just changes syntax in a way that people have to learn.

I would argue it's the opposite. It isn't obvious that the version of go1.21rc2 is "go1.21rc2" without being familiar with Go versions, but most people who know semver (which is most people) would guess "1.21.0-rc2".

Yes, it would use a semi-standard syntax, but it would still be our own defined subset of Semver, not complete Semver.

What do you mean?

When I first started working on the GOTOOLCHAIN code, I handled Go versions in MVS by defining conversion functions from Go version syntax -> Semver and then Semver -> Go version syntax. That was pretty tricky and annoying, and it was difficult to catch all the places where the "internal" Semver form might leak out. @bcmills pointed out to me that the MVS library did not assume Semver at all, and that by making a minor adjustment I could let it operate directly on the Go version syntax. That was an enormous simplification and cleaned up tons of rough edges.

It sounds like all of that complexity would be avoided by using the same versioning scheme, as you described at the end here. Using semver for modules and the language would have the same simplification, right?

We'd still have to support the go syntax for all the old versions.

Couldn't the toolchain map old version strings to their semver equivalents? There are maybe a hundred of them? There's no need to parse the old versions.

We'd have to teach people the new rc syntax

"-rc2" vs. "rc.2" doesn't seem that complicated to learn. Only a small minority of Gophers work with RC releases anyway.

and then have to explain to people why some versions are "1.21rc2" while others are "1.22.0-rc.1" or whatever we decide on.

In my opinion, this would quickly pass, and wouldn't even be a big deal when it happens. "brew upgrade go" doesn't deal with Go versions at all. Most users are on a recent, supported version.

We'd have to invent some stand-in for the concept of the language version (1.21 as different from 1.21.0).

Why wouldn't 1.21 work? It's obvious it's not a semver.

The code is written and everyone understands the current syntax.

It can be written again, right?

Most importantly, the GOTOOLCHAIN code understands the current syntax.

It can be written to understand the new syntax, right?

If we switched to semver in the future, that would invalidate all the old toolchains being used perfectly well to run newer versions of Go.

I don't understand what this is saying. The old and new version schemas can coexist.

At this point I think the ship has sailed, and the island it landed on is Go's version syntax, not semver.

It doesn't seem that way to me. We've added the patch version, and now we could go the rest of the way.

It just changes syntax in a way that people have to learn.

I would argue it's the opposite. It isn't obvious that the version of go1.21rc2 is "go1.21rc2" without being familiar with Go versions, but most people who know semver (which is most people) would guess "1.21.0-rc2".

People who know semver might guess 1.21.0-2 or 1.21.0-releasecandidate.2 or 1.21.0-pre.2 or any number of other possibilities. Nothing about semver dictates the specific syntax 1.21.0-rc.2. Also note that you used the wrong semver syntax in this reply: we would surely use 1.21.0-rc.2 not 1.21.0-rc2. This only proves the point that there's not one obvious semver answer. We can't help "people who know semver" because semver does not constrain the space.

People who have used previous Go release candidates know the numbering already. We can help those people by continuing to use the same syntax.

Yes, it would use a semi-standard syntax, but it would still be our own defined subset of Semver, not complete Semver.

What do you mean?

I meant that we'd be using 1.21.0-rc.2 not 1.21.0-rc2 or 1.21.0-pre.2 or 1.21.0-rc.2+foo or any other number of valid semver syntaxes that would not be valid Go syntaxes.

When I first started working on the GOTOOLCHAIN code, I handled Go versions in MVS by defining conversion functions from Go version syntax -> Semver and then Semver -> Go version syntax. That was pretty tricky and annoying, and it was difficult to catch all the places where the "internal" Semver form might leak out. @bcmills pointed out to me that the MVS library did not assume Semver at all, and that by making a minor adjustment I could let it operate directly on the Go version syntax. That was an enormous simplification and cleaned up tons of rough edges.

It sounds like all of that complexity would be avoided by using the same versioning scheme, as you described at the end here. Using semver for modules and the language would have the same simplification, right?

Maybe but it doesn't really seem like a simplification.

We'd still have to support the go syntax for all the old versions.

Couldn't the toolchain map old version strings to their semver equivalents? There are maybe a hundred of them? There's no need to parse the old versions.

I suppose.

We'd have to teach people the new rc syntax

"-rc2" vs. "rc.2" doesn't seem that complicated to learn. Only a small minority of Gophers work with RC releases anyway.

It would be "-rc.2" vs "rc2". Another mistake using the syntax, which proves my point that we should not try to teach people a different syntax. Let's keep using the one we have.

and then have to explain to people why some versions are "1.21rc2" while others are "1.22.0-rc.1" or whatever we decide on.

In my opinion, this would quickly pass, and wouldn't even be a big deal when it happens. "brew upgrade go" doesn't deal with Go versions at all. Most users are on a recent, supported version.

History matters (in my opinon of course). Not everyone updates frequently or keeps up with the issue tracker like you do. Churn is painful.

We'd have to invent some stand-in for the concept of the language version (1.21 as different from 1.21.0).

Why wouldn't 1.21 work? It's obvious it's not a semver.

In go.mod files, for require lines, if you write v1.21 it means v1.21.0.

The code is written and everyone understands the current syntax.

It can be written again, right?

Not really, no. Go 1.21 is in the release freeze. We are not going to rewrite the code at this point.

Most importantly, the GOTOOLCHAIN code understands the current syntax.

It can be written to understand the new syntax, right?

Again, no. Go 1.21 is in the release freeze.

If we switched to semver in the future, that would invalidate all the old toolchains being used perfectly well to run newer versions of Go.

I don't understand what this is saying. The old and new version schemas can coexist.

It is an explicit goal that Go 1.21 can invoke future toolchains based on the go line in the go.mod file.

When Go 1.22rc1 comes out, Go 1.21 will work fine with things like GOTOOLCHAIN=go1.22rc1 go test. If Go 1.22 changes the version syntax, then Go 1.21 will NOT work fine with GOTOOLCHAIN=go1.22-rc.1 go test, because it will not understand the syntax.

At this point I think the ship has sailed, and the island it landed on is Go's version syntax, not semver.

It doesn't seem that way to me. We've added the patch version, and now we could go the rest of the way.

We will have to disagree on that.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group