Desired Outcome

I would like to use the methodology described here in this blog post => https://blog.golang.org/v2-go-modules to support users who aren't using go modules.

Specifically, that would mean moving to a directory setup like so:

github.com/urfave/cli @ master branch
/go.mod    → module github.com/urfave/cli
/v2/go.mod → module github.com/urfave/cli/v2

Risks

This proposed change will make the git repo most "noisy", in that there will be more total files in the repo. It will be a bit more confusing to direct new contributors to the right place to add code. I think both those issues are easily solved with strong documentation, though!

Motivation

The motivation here is the many many cases where we broke someone who wasn't using go modules, or were the reason why someone had to start using go modules. Examples:

• cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver) #925 (comment)
• cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver) #925 (comment)
• cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver) #925 (comment)
• after cli.GlobalString was removed Google Cloud Print Connector cannot be built #926 (comment)
• v1 bug: Not everyone is using modules, mind what you push to master #947 (comment)
• Add go modules and update cli flag creation to work with latest urfave/cli changes anubhavmishra/envoy-consul-sds#4
• Go modules ethereum/go-ethereum#20164

Non-goals

Even with this proposal, I would still consider v1 go be "locked" at 1.22.X. Which is to say, I am by no means suggesting that we start merging feature PRs into v1! v1 would remain in its "critical bug fixes only" state, it would simply live in the master branch.

Our Paths Forward

This section describes how our paths forward from here would effect each of the following types of users:

1. users using GOPATH mode, who have already updated
2. users using GOPATH mode, who have not updated yet
3. users using vendoring
4. users using go modules

If we don't make this change

1. users using GOPATH mode, who have already updated

These users will be broken again when we update the package to v3 #833. This will also be broken again if we update to v4, or v5, etc...

2. users using GOPATH mode, who have not updated yet

All of these users are currently broken, and will remain broken unless they take some action. The most common actions people take are:

1. swap to using go modules, or
2. update to v2

3. users using vendoring

These users are currently ok, and will remain ok

4. users using go modules

These users are currently ok, and will remain ok

If we make this change

1. users using GOPATH mode, who have already updated

These users will be broken once, because they will update to downgrade from v2 => v1

2. users using GOPATH mode, who have not updated yet

These users will be fixed

3. users using vendoring

These users are currently ok, and will remain ok

4. users using go modules

These users are currently ok, and will remain ok

A comparison of the options

As you can read above, users in group (3) and (4) will be fine regardless of what we do.

So this decision is really about users in groups (1) and (2), we will be affected in the following way:

• if we dont make this change
  • #ff0000 group 1 users will be broken at least once in the future
  • #ff0000 group 2 users will be broken forever
• if we do make this change
  • #ff0000 group 1 users will be broken only once
  • #00ff00 group 2 users will be fixed

In Conclusion

This problem space is complex, but the cost of not making this change is much higher than the cost of making it.