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.

Sign up for GitHub

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

Jump to bottom

[meta] Ship v2 #172

Closed
mjackson opened this issue Dec 6, 2015 · 44 comments
Closed

[meta] Ship v2 #172

mjackson opened this issue Dec 6, 2015 · 44 comments

Comments

@mjackson
Copy link
Member

mjackson commented Dec 6, 2015

I think the only thing that's left to ship v2 is to remove all the deprecated/weird code and release. Any objections?

/cc @rackt/routing
@taion
Copy link
Contributor

taion commented Dec 6, 2015

These two need to be fixed: https://github.com/rackt/history/blob/master/modules/useQueries.js#L107-L113

And dropping createLocation like you said before.

@taion
Copy link
Contributor

taion commented Dec 6, 2015

Oh, and #163 - if we want to change the default for createHashHistory.

@taion
Copy link
Contributor

taion commented Dec 6, 2015

We're also in a bit of an odd spot right now w/r/t the deprecations, because we haven't updated React Router's internals yet to switch to the new APIs (e.g. on <Link>).

Especially if we think we'll ship history v2.x before we ship React Router v1.1.x, then we might want to put out a stopgap release of React Router that doesn't change its APIs, but updates to use the new history APIs.

This was referenced Dec 6, 2015
Closed
Merged
@timdorr
Copy link
Member

timdorr commented Dec 7, 2015

We can just delay the deprecations until after we land and release those other issues you've mentioned.

@taion
Copy link
Contributor

taion commented Dec 7, 2015

👍

@taion
Copy link
Contributor

taion commented Dec 7, 2015

Or unwind them anyway.

@mjackson
Copy link
Member Author

mjackson commented Dec 7, 2015

I'd like to get history v2 out the door ASAP just so I can check something off my TODO list. Too many loose ends makes it easy for me to forget something :)

I don't actually consider #163 a breaking change. Everything should work as before after that change, including URLs with the hash. Also, I'm not 100% sure what the implementation is going to look like there, so I'm happy to move forward with history v2 without it.

Now that #173 is merged, I think we're ready to cut a 1.15 release. v2 after that will just be removing a bunch of deprecated stuff.

@taion
Copy link
Contributor

taion commented Dec 7, 2015

What do you think about shipping a React Router release that uses the new API, minus the Router-side API changes? I definitely want these API cleanups, but I also want our users to be able to use them. As-is, Router users won't be able to use history v2 at all until we ship something semi-updated (mostly just remix-run/react-router#2659) on the Router side.

@mjackson
Copy link
Member Author

mjackson commented Dec 7, 2015

Agreed. Let's ship a router 1.1 release that uses history v2. We can put the changes that are specific to remix-run/react-router#2646 in a separate branch to be merged back into master after the 1.1 release.

@timdorr
Copy link
Member

timdorr commented Dec 7, 2015

I'm in agreement about a v1.15.0 release here. We should use that version in router 1.1, which will remove usage of any deprecated APIs. Then we can go 2.0 on router and history in lockstep, easing the transition path, since they won't have to update things twice.

@mjackson
Copy link
Member Author

mjackson commented Dec 7, 2015

ok, so are we ready for a 1.15 release? Looks to me like we are.

@timdorr
Copy link
Member

timdorr commented Dec 7, 2015

Yep, you can cut that right now.

@taion
Copy link
Contributor

taion commented Dec 7, 2015

With the <Link> PR merged, does the router have any dependencies on the old APIs? At that point it should work with 2.x as well. I think we can support both history 1.15.x and 2.x by using just the 2.x API.

A little unfortunate to have to move some code out of the way for a bit. I didn't realize we'd get these changes on the history side ready so quickly. That's a very good problem to have though! (:

@timdorr
Copy link
Member

timdorr commented Dec 7, 2015

Yep. It's mostly minor stuff. I was planning on getting all of that alongside updating things to use this.context.router, but I can move up that effort to remove any deprecation warnings.

@taion
Copy link
Contributor

taion commented Dec 7, 2015

Yeah, I think we want to move the context.router stuff onto a branch, and just get rid of the deprecated API use. The changes actually shouldn't collide at all. Then we can just mark the peer dependency as ^1.15.0 || 2.x.

@mjackson
Copy link
Member Author

mjackson commented Dec 7, 2015

OK. I'll cut a 1.15 history release and we can remove the last remaining bits from the router that use pushState/replaceState.

@mjackson
Copy link
Member Author

mjackson commented Dec 7, 2015

I'll dig in here and try to get a PR up by EOD that removes all deprecations for v2. I'm sure I'll miss a few things, but hopefully you guys will be able to catch me :)

If either of you would like to take a stab at a PR on the router that makes the changes we discussed above that would be great.

mjackson added a commit that referenced this issue Dec 8, 2015
@mjackson
Remove deprecations
6769172 
Closes #172
mjackson added a commit that referenced this issue Dec 9, 2015
@mjackson
Remove deprecations
b525b51 
Also, update createLocation signature and remove it from top-level
exports.

Closes #172
@timdorr timdorr mentioned this issue Dec 9, 2015
Closed
@mjackson
Copy link
Member Author

ok, now that we've shipped 1.16 that should fix everyone's builds and stop the flow of issues in the router. If, at this point, we ship a version 1.17 with the warnings back in, we'll just break everyone's build again.

So, I propose that we ship what we currently have on master as history v2. It's full of deprecation warnings, but the recommended API is pretty much exactly what we want it to be and people won't get auto-upgraded to it. In a few weeks, we can ship history v3 that removes all the deprecated code. In the mean time, we can ship bug fixes and features on the 2.x line.

@mjackson mjackson mentioned this issue Dec 10, 2015
Closed
@timdorr
Copy link
Member

timdorr commented Dec 10, 2015

Agreed. @ryanflorence's logic for doing a major version deprecation schedule on router would apply well here too.

I can get a 1.0.3 of router together so people get upgraded without confusion over peerDeps or warnings. Can you publish that?

@mjackson
Copy link
Member Author

@timdorr yep, that'd be great. Thank you :)

@timdorr
Copy link
Member

timdorr commented Dec 10, 2015

Ready in remix-run/react-router#2702. It'll all be ready in the 1.0.x branch.

@timdorr
Copy link
Member

timdorr commented Dec 23, 2015

So, we've removed all the relevant deprecation warnings. Are we going to ship 2.0 with them added back in or just not ship a warning version?

@taion
Copy link
Contributor

taion commented Dec 23, 2015

We need a version with both the new API and the deprecations to give users a good upgrade path. From Discord, it sounds like it'd be better to make that 2.0.0 rather than 1.18.0.

@ryanflorence
Copy link
Member

Yes, 2.0 with warnings, then in no less than 3 months, release 3.0 w/o them.

@mjackson
Copy link
Member Author

mjackson commented Jan 3, 2016

I'm planning on shipping 2.0 w warnings tonight. If anyone has any last-minute input, please speak up!

@taion
Copy link
Contributor

taion commented Jan 3, 2016

What do you think of shipping this as an RC just in case we missed something? We caught a few things over the last few days in the Router that we missed before cutting the initial RC. It'd be awkward to have to do another major version bump or something just in case we need to change some API we didn't notice.

@mjackson
Copy link
Member Author

mjackson commented Jan 3, 2016

Sure. I'll cut 2.0.0-rc1 tonight then. Thanks for the suggestion.

On Sat, Jan 2, 2016 at 8:06 PM Jimmy Jia [email protected] wrote:

What do you think of shipping this as an RC just in case we missed
something? We caught a few things over the last few days in the Router that
we missed before cutting the initial RC. It'd be awkward to have to do
another major version bump or something just in case we need to change some
API we didn't notice.

—
Reply to this email directly or view it on GitHub
#172 (comment).

@mjackson
Copy link
Member Author

mjackson commented Jan 3, 2016

ok, 2.0.0-rc1 is out. Please kick the tires.

@taion
Copy link
Contributor

taion commented Jan 3, 2016

Our dist-tags look a bit weird on npm:

jjia@jjia-mbp:~/vendor/react-router (upgrade-history-dep)$ npm dist-tag ls history
latest: 2.0.0-rc1

jjia@jjia-mbp:~/vendor/react-router (upgrade-history-dep)$ npm dist-tag ls react-router
beta: 2.0.0-rc4
latest: 2.0.0-rc4

Probably we should still have respectively 1.17.0 and 1.0.3 on latest with the RCs tagged beta?

@mjackson
Copy link
Member Author

mjackson commented Jan 3, 2016

Good catch, @taion. Though I think it's a bit weird to use the beta tag instead of rc. I'll update.

@mjackson
Copy link
Member Author

mjackson commented Jan 6, 2016

Just an update here: I'd like to use the next npm dist-tag across all our repos for the next upcoming release. It's also what React core uses:

$ npm dist-tag ls react
0.10.0-rc1: 0.10.0-rc1
0.11.0-rc1: 0.11.0-rc1
latest: 0.14.5
next: 0.14.0-rc1

@knowbody
Copy link
Contributor

knowbody commented Jan 6, 2016

👍 @mjackson 

@timdorr
Copy link
Member

timdorr commented Jan 6, 2016

James was doing the same thing on redux-simple-router too. I'm all for it!

@timdorr
Copy link
Member

timdorr commented Jan 21, 2016

@mjackson Since we got #200 merged in, can we get a 2.0.0-rc3 cut? It fixes some things needed for router to go 2.0.

We should be able to do a 2.0.0-rc6 on router just as a last-minute double-check for issues and be good to go 2.0 here and on router. 🤘

@mjackson
Copy link
Member Author

mjackson commented Feb 3, 2016

Sorry for the silence everyone. Been traveling a lot lately. I'll cut 2.0.0-rc3 today.

Edit: done!

@taion taion closed this as completed Feb 3, 2016
@taion taion reopened this Feb 3, 2016
@taion
Copy link
Contributor

taion commented Feb 3, 2016

Great, thanks! Let me fix #221 real quick.

@taion
Copy link
Contributor

taion commented Feb 3, 2016

Sorry, finger slipped.

@mjackson
Copy link
Member Author

mjackson commented Feb 3, 2016

Awesome, thanks @taion. Anything else you'd like to do before we cut version 2? We can always do minor/patch releases for new API and/or bugs afterward.

@taion
Copy link
Contributor

taion commented Feb 3, 2016

Nope, this should be it – just want to get this in because it's a pretty trivial fix.

@taion
Copy link
Contributor

taion commented Feb 3, 2016

Fix is on #222.

@mjackson
Copy link
Member Author

mjackson commented Feb 3, 2016

OK, looks like we're good to go ahead and cut v2.

@taion
Copy link
Contributor

taion commented Feb 3, 2016

👍

@taion
Copy link
Contributor

taion commented Feb 4, 2016

@mjackson Can you fix the npm tags? This doesn't look right:

latest: 2.0.0-rc3
next: 2.0.0-rc1
rc: 2.0.0-rc1

@mjackson
Copy link
Member Author

mjackson commented Feb 4, 2016

@taion Fixed dist-tags and cut v2.0.0 release today 🎉

Thanks everyone for your help!

@mjackson mjackson closed this as completed Feb 4, 2016
@lock lock bot locked as resolved and limited conversation to collaborators Jun 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@timdorr @mjackson @ryanflorence @taion @knowbody