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: add 'go release' #26420

Open
rsc opened this Issue Jul 17, 2018 · 16 comments

Comments

Projects
None yet
10 participants
@rsc
Contributor

rsc commented Jul 17, 2018

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

This comment has been minimized.

Contributor

ianlancetaylor commented Jul 17, 2018

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

This comment has been minimized.

Contributor

komuw commented Jul 18, 2018

  • 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

This comment has been minimized.

Contributor

crawshaw commented Jul 21, 2018

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

This comment has been minimized.

Member

mvdan commented Jul 21, 2018

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 bcmills added the modules label Jul 30, 2018

@bcmills

This comment has been minimized.

Member

bcmills commented Jul 30, 2018

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

This comment has been minimized.

thepudds commented Aug 15, 2018

  • 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

This comment has been minimized.

thepudds commented Aug 15, 2018

  • Consider automatically running the equivalent of:
    • go mod verify
    • go mod tidy
  • Consider validating the consistency of the current vendor directory, if any

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

This comment has been minimized.

thepudds commented Aug 19, 2018

  • 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).

@bcmills

This comment has been minimized.

Member

bcmills commented Sep 25, 2018

  • warning if a replace directive points to a local path in the same repository whose contents have changed since the required version of that module.

(Related to #27542.)

@dmitshur

This comment has been minimized.

Member

dmitshur commented Oct 12, 2018

/cc @bradleyfalzon who created apicompat, a tool to check for the introduction of backwards incompatible changes, which is relevant here.

@Sajmani

This comment has been minimized.

Contributor

Sajmani commented Oct 12, 2018

Recommend which kind of semver change to make, patch bump or minor bump.

Major bumps (incompatible changes) are more involved, as they require a new import path & work to allow the new major version to coexist with previous ones (e.g., by wrapping & adding aliases, or extracting package-level state into a shared internal package).

@Sajmani

This comment has been minimized.

Contributor

Sajmani commented Oct 12, 2018

Detect when creating go.mod in a directory under an existing go.mod (is this an error?)

CC @hyangah

@bcmills

This comment has been minimized.

Member

bcmills commented Oct 24, 2018

I think @jba is planning to do some preliminary work, but this needs more design. Pushing to 1.13.

@bcmills bcmills modified the milestones: Go1.12, Go1.13 Oct 24, 2018

@jba

This comment has been minimized.

jba commented Oct 24, 2018

I'm working only on the part that recommends which part of the semver to bump.

@thepudds

This comment has been minimized.

thepudds commented Oct 25, 2018

  • Consider a warning or some mode to check if there are different version requirements for a shared v0 dependency.

For example, if module A requires v0.1.0 of dependency D, and module B requires v0.2.0 of dependency D, then the build will use v0.2.0 of D. However, that might subtly or explicitly break A, given v0 is a "compatibility free zone", and hence this scenario might be worth some flavor of detection or warning.

Related to #28395 and possibly #28396.

@jba

This comment has been minimized.

jba commented Nov 11, 2018

The spec/design doc for API compatibility checks is ready. Implementation is in review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment