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

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

Closed
thepudds opened this issue Oct 25, 2018 · 1 comment

Comments

@thepudds
Copy link

@thepudds thepudds commented Oct 25, 2018

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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Nov 13, 2018

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.

@bcmills bcmills closed this Nov 13, 2018
@golang golang locked and limited conversation to collaborators Nov 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants
You can’t perform that action at this time.