I think this would be really valuable to have. Semantic import versioning is a common frustration people have with modules, and anything we could do to make it a better user experience would be helpful.

I'd hesitate to add this functionality to cmd/go. It has a lot of responsibilities, but it's focused on build and dependency management, and it would be good not to expand the scope too far beyond that. That said, there is some precedence in go fix.

We should also consider how this fits into any long-term plans for automatic refactoring. For example, is this something gopls could do? Also, should we provide a way to migrate automatically across incompatible API changes?

cc @ianthehat @stamblerre

I definitely think it would be useful to provide a tool that can add (or update) the /vN suffix in a module's module directive and update its internal import statements to match.

I'm less convinced on updating consumers; I think an author-side tool like goforward is probably a better fit for that in the general case, although there may be some benefit to reducing indirection on the consumer side. I think the consumer-updating tool should probably be separate: if we're using forwarding declarations anyway, then the v1-to-v2 upgrade looks a lot more like example-based refactoring than mere path-rewriting. (And that provides a way to migrate across incompatible changes, too.)

I think this is important on the module consumer side, too, but I admit I don't have a sense of how frequent and how inconvenient these upgrades are.

I spoke with @ianthehat this morning. There's some ongoing work adding automated refactoring through gopls. Some of the points below are being actively worked on, others are just ideas.

• Renaming symbols and other traditional refactoring.
• Applying suggested changes from the analysis framework.
• Explaining entries in go.sum.
• Applying suggested upgrades when editing go.mod.

The last idea was upgrading a particular module, not replacing it with a new major version. But maybe we could work this in, too.

I think this is important on the module consumer side, too, but I admit I don't have a sense of how frequent and how inconvenient these upgrades are.

I think it is (arguably) even more important to support the consumer side, or at least I wouldn't suggest forgoing the consumer side.

It is not just how frequently the upgrades occur -- the adoption of modules by a v2+ dependency means a consumer needs to go through this process, even if there is no actual major version upgrade involved (or if the "major version" upgrade was solely due to the adoption of modules).

As has been said before, one would hope there are usually more consumers than authors for most open source modules.

I think an author has more moving parts and it is harder for an author to get right, but the consumer pain here is more frequent, I think.

People are currently doing this with things like sed, and frequently are not pleased to be doing so.

For me, the best answer is "the tooling handles it for you".

go fix or goforward could be alternative solutions in the future, but I think there is a lot to be said for a standalone golang.org/x utility targeted at this problem. gopls could be nice, but also seems the plate there is pretty full both on the gopls and editor/IDE sides.

Hi @bcmills @jayconrod, I'm curious for any latest thinking here regarding a possible location for such a tool?

Two possible locations discussed previously:

1. a standalone tool in golang.org/x/tools
2. gopls

(And being part of cmd/go is not very desirable, I think).

One way to look at it -- Go 1.4 introduced optional custom import path checking, such as:

package zap // import "go.uber.org/zap"

In part to help smooth adoption and minimize disruption, fiximports was created by the core Go team in 2015 or so:

https://godoc.org/golang.org/x/tools/cmd/fiximports

Command fiximports

The fiximports command fixes import declarations to use the canonical import path for packages that have an "import comment" as defined by https://golang.org/s/go14customimport.

It's probably fair to say that Semantic Import Versioning is a larger change to the ecosystem than optional import path checking in Go 1.4...

There's been a massive amount of effort that has gone into modules, of course. Mainly just wanted to circle back to this given there is likely to be another wave of new adoptors with Go 1.14.

@marwan-at-work I don't want to put you on the spot, but would you be willing for https://github.com/marwan-at-work/mod to be used (by someone?) as a starting point for a standalone golang.org/x/tools tool, if that ends up being a desirable choice?

Also, regarding the current dependencies for github.com/marwan-at-work/mod:
https://github.com/marwan-at-work/mod/blob/master/go.mod

Now that https://golang.org/x/mod exists, do would it be reasonable for those dependencies to be more stripped down to be friendly to living in golang.org/x/tools (again, if that ends up being desirable)?

@thepudds, note that a key difference between semantic import versioning and custom import path checking is that unversioned import paths remain usable and supported for major versions 0 and 1 and repositories that lack explicit go.mod files. (Non-canonical import paths, on the other hand, result in a compile-time error, I believe.)

For folks who want to resume support of a previously-unversioned module path, we changed the go command to use +incompatible versions less aggressively in Go 1.14: module authors who want to continue development on those paths now have the option to resume the unversioned path (at major version 0 or 1) without confounding go get -u.

So, while I agree that an automatic upgrade tool might be useful, I don't think that Go 1.14 makes it particularly more urgent than before.

Hi @bcmills, for new adoptors, partly I am just thinking about how each major release since 1.11 has triggered at least a mini-wave of adoptors, but in addition Go 1.14 has this statement:

Module support in the go command is now ready for production use, and we encourage all users to migrate to Go modules for dependency management.

I was not trying to suggest that something about Go 1.14 itself makes this more urgent, but rather the (likely) uptick around Go 1.14 is another time to think about whether or not it makes sense to have a standalone tool in golang.org/x (or gopls) to help smooth the transition.

Semantic Import Versioning as you know sometimes generates "interesting" discussions within pockets of the ecosytem (e.g., two semi-random samples: 1, 2).

Personally, I would be happier knowing that a tool (or gopls) is at least planned to help take some of the friction out...

We're currently looking to bring go mod support to github.com/gomodule/redigo but as there was already a v2.0.0 tag which is actually behind master so we need to jump to straight to v3.0.0.

While this seems simple the user experience is far from a good one as the imports for all consumers need to updated from github.com/gomodule/redigo/redis to github.com/gomodule/redigo/redis/v3 which in a large code base will be laborious to say the least.

We've had a PR hanging for some time and I was looking to pull the trigger until I tested the flow on a separate repo which clearly demonstrated how painful this was going to be for existing users.

Based on this experience I agree that a core tool automate this process is key to help eliminate developer pain when it comes to this area of go mod.

@stevenh, note that as of Go 1.14 you can resume the v1 version when adopting modules if you don't want to update all of the import paths.

(See https://golang.org/doc/go1.14#incompatible-versions.)

ooo thanks for the heads up on that, worth considering.

As a relative newb Go developer, I'm confused as heck by the module versioning process - thought I'd add my two pennies here. Does it need to be so hard to update to the latest major version? I understand the idea of the promise of backward compatibility at the minor version level, but can we not have the "default" mode of "go get -u update" to latest minor version safely, and let "go get -u=major" perhaps update major versions and happily break things?

Here's another tool which does the same thing: https://github.com/icholy/gomajor

I have also written a tool that does this: https://github.com/nathanjcochran/upgrade