If gomajor list shows me a few updates, either minor or major version bumps, it would be nice to be able to use gomajor get with those directly. Perhaps there's a way, but I haven't found one via the help docs, so I manually copy-paste the new module paths into gomajor get.

Perhaps gomajor get all?

In a few projects, I see gomajor list -major make suggestions like:

github.com/libp2p/go-libp2p: v0.21.0 [latest v6.0.23+incompatible]
github.com/mattn/go-sqlite3: v1.14.16 [latest v2.0.3+incompatible]

The suggestions are technically correct, because the upgrades are indeed newer major versions, and they aren't retracted via the modules system.

However, they're wrong: they are older versions which were published either before switching to Go modules, or by mistake.

I reckon that gomajor list -major should, by default, ignore major version upgrades which add the +incompatible component. An upgrade from v2.0.0+incompatible to v3.0.0+incompatible would be shown by default, because it's not making anything worse, but v1.0.0 to v3.0.0+incompatible would not be shown by default, with the understanding that often it will be a bad idea. Nowadays, if a module really does bump their major version, it's incredibly rare that they will publish as +incompatible.

One could still get the old behavior via a flag, like -incompatible.

Add a move command for moving packages in a module.

$ gomajor move pkg/foo internal/bar

Behaviour:

• Move the directory
• Change the package declaration.
• Rewrite import paths.

Nice tool.

I was thinking .. as you’ve seen discussion at 44550, I need to try it, but a replace of a SIV to one without may help bandaid the experience I’m suggesting in that proposal. What if this tool had -alias which you could pass a package name without SIV and it would add replace to alias. Then could add -alias-all to alias every module without passing a specific one.. and maybe -alias-skip too for exclusion.

I usually use Makefiles, so something like that could be used to manage an experience similar to what I’m describing in 44550. What do you think?

Cc @zikaeroh

I've added a failing test for the go-systemd module. If I go to the proxy URL directly, it gives me a blank page:

https://proxy.golang.org/github.com/coreos/go-systemd/@v/list

The apidiff subcommand will be a more ergonomic interface to the x/exp/apidiff package.

Show the apidiff between two import paths

gomajor apidiff github.com/deckarep/[email protected]  github.com/deckarep/[email protected]

• ~~this works outside of a module.~~
• if only one path is provided, the other is inferred from your go.mod.

Here's an example of a nested module: https://github.com/go-redis/redis/blob/master/extra/rediscmd/go.mod

module github.com/go-redis/redis/extra/rediscmd

go 1.15

require (
	github.com/go-redis/redis/v8 v8.4.4
	github.com/onsi/ginkgo v1.15.0
	github.com/onsi/gomega v1.10.5
)

If I run gomajor next -path at the root of the go-redis/redis it will rewrite imports to github.com/go-redis/redis/extra/rediscmd to github.com/go-redis/redis/v9/extra/rediscmd.

The kubernonsense go.mod uses replace to pin their dependencies. This bad technique has leaked into repositories which extend kubernetes. I think we can support this use-case with the following 2 behaviours.

1. Don't skip replaced modules in gomajor list
2. If a required module is replaced with the exact same version, gomajor get will update both the required and and replaced version.

$ gomajor get github.com/russross/[email protected]
go get github.com/russross/[email protected]+incompatible

The latest version is: github.com/russross/blackfriday/[email protected]. Since the latest +incompatible version is v2 it checks for a github.com/russross/blackfriday/v3 import path which doesn't exist.

I've seen some people using the get sub-command to rewrite imports when incrementing their module's major version. There should be a dedicated command for that use-case. This command will update go.mod and rewrite all imports in the module.

Examples:

// increment the major version
gomajor path -next

// specify the version to use the path
gomajor path -version v5

// specify the whole path to use
gomajor path "github.com/icholy/gomajor/v10"

I ran the following:

gomajor get github.com/go-redis/redis/v8
go get github.com/go-redis/redis
go: github.com/go-redis/redis upgrade => v6.15.9+incompatible
bridge/adapters/sources/redis.go: github.com/go-redis/redis/v8 -> github.com/go-redis/redis
bridge/adapters/targets/redis.go: github.com/go-redis/redis/v8 -> github.com/go-redis/redis

Instead of getting the latest version of v8, it downloaded v6.15.9+incompatible

I'm looking at gomajor to evaluate when I need to update versions and for public repo's it's fine. However for private repo's it does not list them.
Is this something that is planned for the future.

My envvar GOPRIVATE is already set correctly.