Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

maint: release 2.X #826

Closed
coilysiren opened this issue Aug 3, 2019 · 39 comments
Closed

maint: release 2.X #826

coilysiren opened this issue Aug 3, 2019 · 39 comments
Assignees
Labels
kind/maintenance about releasing / CI / Github / other kind of "meta" project maintenance work status/claimed someone has claimed this issue

Comments

@coilysiren
Copy link
Member

coilysiren commented Aug 3, 2019

If anyone is interested in the work of merging the master branch into v2, add let us know here with a "🤚I'm interested in working on this" comment!


The comments below describe a random assortment of release 2.X concerns 📝

@coilysiren
Copy link
Member Author

I'm thinking that I'll keep the current 2.0 branch as release 2.0 forever, and the very next release I make will be 2.1.

@coilysiren
Copy link
Member Author

I'm also going to try to merge 2.0 into master ASAP. I may keep maintaining a 1.0 branch with bugfixes? If people are interested in that.

@AudriusButkevicius
Copy link
Contributor

Isn't that a breaking change in terms of API? I am not sure its cool everyone that don't do vendoring. Also, current api and implementation is battle tested, v2 is not.

@coilysiren
Copy link
Member Author

Isn't that a breaking change in terms of API? I am not sure its cool everyone that don't do vendoring.

My understanding of the go community is that the vast majority of people install from a tag, eg. 1.2.4 - and don't install from the default branch, eg master. So there's no API compatibility guarantee around the master branch.

That said, I just checked the yaml package and apparently they changed their default branch to be v2 https://github.com/go-yaml/yaml. So that may be the way to go here.

Also, current api and implementation is battle tested, v2 is not.

That's true! Are you suggesting we have a beta release period, or similar?

@coilysiren
Copy link
Member Author

Got a comment via Stephen Houston in the gophers general channel on slack

Traditionally I would say you keep master based off your current stable with bugfixes added in to prepare for point releases ... I.e. if your current stable is 1.0 ... master is on 1.0 but with bugfixes added in to be able to tag 1.1 etc... you have a develop branch that is for features/future releases... when you get ready to do a new major release, i.e. v1 -> v2... master becomes develop and you tag... and then master follows 2.0 and gets bugfixes for 2.0 in order to do point releases 2.1 etc... and develop moves on to new features/future releases.

@coilysiren
Copy link
Member Author

to echo @tsingson's comment here

this gopkg.in/urfave/cli.v2 is working fine for me in product about half year.

#824 (comment)

@coilysiren coilysiren added the kind/discussion is for discussion label Aug 3, 2019
@coilysiren
Copy link
Member Author

There's some really good discussion in this thread about go packaging and release a V2 #840 (comment)

@AudriusButkevicius
Copy link
Contributor

I am not sure what the plan is here.
I am not a fan of the current "there are two different incarnations of the library in a single repo" stuff.

Ideally we'd have only one library that is the right library for everyone, and that would be on master.

@marwan-at-work
Copy link
Contributor

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.

@coilysiren
Copy link
Member Author

I am not a fan of the current "there are two different incarnations of the library in a single repo" stuff.

I agree 👍

@AudriusButkevicius
Copy link
Contributor

AudriusButkevicius commented Aug 6, 2019

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

Presumably this requires go.mod to be updated with a /v2 suffix?
I guess go get github.com/urfave/cli with go version prior to module support would fetch v2 by default?

@marwan-at-work
Copy link
Contributor

@AudriusButkevicius

Presumably this requires go.mod to be updated with a /v2 suffix?

Yes, and also because I imagine the v2 has a different API than v1. Otherwise it wouldn't be v2, it would just be v1.x.x.

I guess go get github.com/urfave/cli with go version prior to module support would fetch v2 by default?

Yes, but since urfave/cli does not have sub-packages that it imports, it should continue to work. Though I'd be a fan of telling users to use modules if they want to use v2 since it'll be the default convention in 1.14 and onwards.

@AudriusButkevicius
Copy link
Contributor

Seems like we're ok to merge v2 into master then.
I guess we need to compare feature parity and make sure we are happy with the API before we do that.

@coilysiren
Copy link
Member Author

In case it's not clear - we will make explicitly sure that V2 has all the same features that V1 has currently 🙂

@AudriusButkevicius
Copy link
Contributor

I haven't really checked what v2 actually looks like. Was it forked or rewritten? Is anyone aware of things that are missing in v1 but not v2 and vica versa?

@coilysiren
Copy link
Member Author

coilysiren commented Aug 6, 2019

For my part, I also don't know anything about the current status of V2

@coilysiren coilysiren added kind/maintenance about releasing / CI / Github / other kind of "meta" project maintenance work and removed kind/discussion is for discussion labels Aug 17, 2019
@coilysiren coilysiren assigned coilysiren and unassigned coilysiren Aug 17, 2019
@coilysiren coilysiren added the help wanted please help if you can! label Aug 24, 2019
@coilysiren
Copy link
Member Author

👋 I updated the first post in this issue to reflect that fact that I specifically am not working on V2 right this moment. If anyone wants to do the work of bringing V2 up to date, let us know here!

@coilysiren coilysiren removed the help wanted please help if you can! label Sep 10, 2019
@asahasrabuddhe
Copy link
Member

asahasrabuddhe commented Sep 11, 2019

I think merging master with v2 is going to be fun. Aside from bringing over features and bugfixes to v2, I think the two things we should consider for v2 are:

1 Getting rid of altsrc and merging the functionality into the main package
2 Restructuring the codebase to reduce the large number of files in the repo root. I thoroughly agree with @AudriusButkevicius about the need of having to clean the chaos.

I think if we can agree on this, I'd like to take this up and move forward toward a stable release. In the coming months, I'd really like to see everyone working on v2 :)

@coilysiren
Copy link
Member Author

Since V2 has been around for quite some time, I would slightly prefer if we made those additional breaking changes in V3? I'm fine adding them to V2 if enough people want that though!

@asahasrabuddhe
Copy link
Member

What we can do in v2 is do the necessary refactors and still keep the existing public API using referencing our new internal API.

For v3, we can clean that up and have a brand new API

I think the more we push this back, the longer and more difficult the transition is going to be. I think we should have a date in mind and then only add new features to v2 and backport necessary features based on a vote. Otherwise, we would keep on maintaining multiple versions for a long time

@coilysiren coilysiren self-assigned this Nov 27, 2019
@coilysiren coilysiren pinned this issue Nov 27, 2019
@coilysiren coilysiren added the status/claimed someone has claimed this issue label Nov 27, 2019
@coilysiren coilysiren changed the title Release 2.X maint: release 2.X Dec 24, 2019
@coilysiren
Copy link
Member Author

2.0 is looking pretty stable now, so I'ma close this ♻️

@coilysiren coilysiren unpinned this issue Jan 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/maintenance about releasing / CI / Github / other kind of "meta" project maintenance work status/claimed someone has claimed this issue
Projects
None yet
Development

No branches or pull requests

4 participants