-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Comments
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. |
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. |
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. |
My understanding of the go community is that the vast majority of people install from a tag, eg. That said, I just checked the
That's true! Are you suggesting we have a beta release period, or similar? |
Got a comment via Stephen Houston in the gophers general channel on slack
|
to echo @tsingson's comment here
|
There's some really good discussion in this thread about go packaging and release a V2 #840 (comment) |
I am not sure what the plan is here. Ideally we'd have only one library that is the right library for everyone, and that would be on master. |
Right, eventually (and hopefully sooner rather than later) the 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 and this way anyone issuing a If someone wanted to get a version not yet tagged, they can still do Now, once we merge Furthermore, once we have And finally, everything should work. The 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. |
I agree 👍 |
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.
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. |
Seems like we're ok to merge v2 into master then. |
In case it's not clear - we will make explicitly sure that V2 has all the same features that V1 has currently 🙂 |
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? |
For my part, I also don't know anything about the current status of V2 |
👋 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! |
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 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 :) |
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! |
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 |
2.0 is looking pretty stable now, so I'ma close this ♻️ |
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 📝The text was updated successfully, but these errors were encountered: