|author||Russ Cox <email@example.com>||Mon Jun 25 22:49:39 2018 -0400|
|committer||Russ Cox <firstname.lastname@example.org>||Mon Jul 02 00:47:08 2018 +0000|
cmd/go/internal/vgo: change get -u to avoid downgrades, prereleases Module requirements should typically be stated in terms of tagged versions, like v1.2.3. But for both bootstrapping and debugging, it is also possible to refer to specific commits using pseudoversions of the form v0.0.0-yyyymmddhhmmss-abcdefabcdef, where abcdefabcdef is a revision identifier (a commit hash for git repos). These pseudoversions are valid semantic versions but chosen so that they sort below any tagged version: if one part of a build wants a tagged version and another part wants a pseudoversion, we explicitly want the tagged version to take priority, so that a dependency deep in your build cannot force it into compiling against a random commit instead of a released (tagged) commit. But this same fact, that pseudoversions sort before tagged versions, confuses "vgo get -u". If the build is using a pseudoversion of a commit from earlier today, it makes no sense for "vgo get -u" to "update" to a latest tagged version that happens to be from last week. This CL changes "vgo get -u" to avoid this kind of accidental downgrade. But if the latest tagged version was committed after the current pseudoversion, then it's OK to upgrade to that tagged version. Now that we can make the effect of "vgo get -u" context-dependent, treat prereleases similarly: never choose to upgrade to a prerelease, but if we're using a prerelease newer than the latest tagged non-prerelease, stay there instead of downgrading. This fixes "vgo get -u" for many real repos, especially ones that must use pseudoversions to get at, say, non-module v17.0.0 of a dependency. Without this logic, "vgo get -u" would rewind to the latest v1, which might be much older. Change-Id: Ie9656b78dc6cc326048921898288dcf588441bf5 Reviewed-on: https://go-review.googlesource.com/121000 Reviewed-by: Bryan C. Mills <email@example.com>
This repository holds a prototype of what the go command might look like with integrated support for package versioning.
See research.swtch.com/vgo for documents about the design.
go get -u golang.org/x/vgo.
You can also manually git clone the repository to
This is still a very early prototype. You are likely to run into bugs. Please file bugs in the main Go issue tracker, golang.org/issue, and put the prefix
x/vgo: in the issue title.