Right, eventually (and hopefully sooner rather than later) the v2 branch should be merged into master branch.

But note that Go Modules completely doesn't care about either branches when you have git tags that are proper semver (which we do)

So my suggestion is the following:

you add a go.mod to the master branch with the following header module github.com/urfave/cli and then creating a new git tag: v1.22.0

and this way anyone issuing a go get github.com/urfave/cli will get the latest version (v1.22.0).

If someone wanted to get a version not yet tagged, they can still do go get github.com/urfave/cli@master and that should still work.

Now, once we merge v2 into master, anyone trying to do go get github.com/urfave/cli@master should fail since v2 is the default master branch and v2 is by definition a breaking change. I think that's totally okay, because anyone still wanting to get the regular v1 even after we merge v2 into master, can still do go get github.com/urfave/cli@latest or go get github.com/urfave/cli or even go get github.com/urfave/cli@v1.x.x (x being whatever number they wish)

Furthermore, once we have v2 merged into master, we need to tag a new release, probably v2.0.0. But we MUST change the go.mod file BEFORE we tag the new release to be module github.com/urfave/cli/v2 so that we maintain semantic import versioning.

And finally, everything should work. The master is the latest v2 version (which is what you suggested above), people can remain to use v1 as they wish (because Go Modules uses regular semver tags, and doesn't care about what's in the master branch). and people can also use v2 through the import path itself since it will have a v2 suffix.

The only thing missing in this process is patch branches, which we can create on the fly (if we know the exact commit before a major bump in master), or we can create stale version branches.

maint: release 2.X #826

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions