cmd/go: add 'go release'

[rsc]

Collecting things we would want a 'go release' command to do:

• API-level compatibility checks
• warning about dependence on prerelease or pseudo-versions.
• checking that root/go.mod and root/v2/go.mod don't both say module foo/v2.

[ianlancetaylor]

• run the tests and make sure they pass
• add a tag to the source code repo if possible and appropriate

[komuw]

• detects api changes and bumps version for you when incompatibility happens.
  similar to http://elm-lang.org/

elm-package diff NoRedInk/json-elm-schema 1.5.0 3.0.0

Comparing NoRedInk/json-elm-schema 1.5.0 to 3.0.0...
This is a MAJOR change.

------ Changes to module JsonSchema - MAJOR ------

    Added:
        additionalItems : JsonSchema.Schema -> JsonSchema.TupleSchemaProperty
        examples : (a -> Json.Encode.Value) -> List a -> JsonSchema.BaseSchemaProperty extras
        maxProperties : Int -> JsonSchema.ObjectSchemaProperty
        minProperties : Int -> JsonSchema.ObjectSchemaProperty
        tuple : List JsonSchema.TupleSchemaProperty -> JsonSchema.Schema
        tupleItems : List JsonSchema.Schema -> JsonSchema.TupleSchemaProperty

    Changed:
      - boolean : List (JsonSchema.BaseSchemaProperty {
                                                      }) -> JsonSchema.Schema
      + boolean : List JsonSchema.BooleanSchemaProperty -> JsonSchema.Schema

      - maxItems : Int -> JsonSchema.ArraySchemaProperty
      + maxItems : Int -> { a |
                            maxItems : Maybe.Maybe Int
                          } -> { a | maxItems : Maybe.Maybe Int }

[crawshaw]

for building automated release notes (to encourage releases to have notes):

• collect any new mentions of Deprecated: in the documentation
• collect RELNOTES from commit messages
• collect fixed bugs from commit messages

[mvdan]

collect RELNOTES from commit messages

Isn't that a bit specific to the Go project itself? I haven't seen it in any other projects. Unless the idea is to start encouraging this practice, which might work out.

[bcmills]

• warning about using versions excluded by other dependencies
• warning about using versions replaced by other dependencies (unless the replacements match)

[thepudds]

• Consider a flag or mode to run tests ignoring local replace/exclude directives in the current module in order to test in the configuration users will see if they import as a dependency.

Useful if the current module is intended to be imported as a dependency but uses local replace/exclude directives that will be ignored by the ultimate top-level module.

(This is the use case described in #24666, but that was closed with a 'Fixes #24666' comment in a CL that caused the issue to be closed automatically, but the CL did not implement the described behavior. Not sure if that 'Fixes #24666' comment was accidentally or deliberately left in the broader CL).

[thepudds]

• Consider automatically running the equivalent of:
  • go mod verify
  • go mod tidy
• Consider validating the consistency of the current vendor directory, if any (edit: this was later added as cmd/go: allow verifying vendored code #27348)

I don't know the degree to which the intent is to automatically do things covered by other commands, but wanted to at least record these as options to consider.

[thepudds]

• Consider a flag or mode of go release that tests as if you had just done go get -u and have the latest available versions of your dependencies, but where your on-disk go.mod requirements are not actually updated. In other words, without actually changing the versions used in your require directives, simulate what would happen if someone downloaded your module, did go get -u, and then tested.

The overall design of the system is such that a module author might not ready to move to the latest version of dependencies for the module's go.mod, but a module's consumers might move to a more recent set of dependencies of that module.

Coupled with the fact that the module author would already naturally be testing against versions used in the actually released require directives, the flag or mode suggested here for go release would mean the high end (latest available) and low end (versions listed in the released go.mod) would both naturally be tested by the module author before release (or at least, this would make it more easy to do so).