cmd/go: consider rule or recommendation that patch releases should be safe bug fixes or security fixes, including for v0 modules

[thepudds]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.11.1 windows/amd64

Suggestion

The official modules proposal includes this statement:

If the Go community as a whole reserved patch versions only for very safe or security-critical changes, then that -p behavior might be useful.

Suggestion: consider making that a more official rule or some other type of advice to the community, including stating it should apply to v0 modules.

It seems the philosophy and behavior of the modules system and MVS work best with v1+ modules, and more generally that v1+ modules provide the best user experience. v0 modules still work, of course, but v0 modules present some additional challenges, including for operations such as go get -u or go get -u=patch.

Adopting such a rule could somewhat improve the safety of something like go get -u=patch in presence of v0 dependencies, though v0 dependencies would still be riskier than v1+ dependencies.

[bcmills]

The cmd/go documentation already links to https://semver.org, and I think that already says enough to cover what we need (emphasis mine):

6. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
7. Minor version Y […] MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. […]
[…]
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

While it also says that for v0 “[a]nything may change at any time”, the intent seems clear: even for v0 releases, minor version are for development and patch versions are for bug-fixes.