Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools: automate major version upgrades for modules #32014
This is a spin out of #31543 ("cmd/go: creating v2+ modules has lower success rate than it could").
Semantic import versioning places the major version in module paths and import paths for v2+ modules, such as:
This approach has value, but empirically it currently seems it can be a challenge to do correctly the first time (e.g., modules with v2 major version semver tags that are missing the required
It also creates additional work for authors and consumers if a module's major version increments, such as from v1 to v2, or v3 to v4, etc.
Tooling should be able to help here in a substantial way.
github.com/marwan-at-work/mod is great for people who know about it and who are willing to trust it.
However, a tool from the broader community won't have the penetration and impact of something from golang.org, or at least it would likely take much longer to get a similar type of penetration following a typical trajectory for a community tool.
Therefore, the suggestion here is to create a golang.org/x utility that can edit
Three sample use cases:
Perhaps one day similar functionality could live in cmd/go (e.g., the closed #27248), but it seems more practical to start with something in golang.org/x.
The suggestion here is that this golang.org/x utility would not do anything with VCS tagging, nor do anything for creating
changed the title
golang.org/x utility to automate major version upgrades for modules (perhaps port marwan-at-work/mod)
May 14, 2019
changed the title
golang.org/x/tools: automate major version upgrades for modules
May 14, 2019
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
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?
I definitely think it would be useful to provide a tool that can add (or update) the
I'm less convinced on updating consumers; I think an author-side tool like
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.
The last idea was upgrading a particular module, not replacing it with a new major version. But maybe we could work this in, too.
referenced this issue
May 23, 2019
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
For me, the best answer is "the tooling handles it for you".