[3.0] Remove deprecated code

[ryanflorence]

This issue tracks the things that need to be deprecated. I'd like to have an issue for each one of these. Also, moving forward, when we deprecate an API, we need to immediately make an issue and assign it to the milestone when we are going to completely remove it.

Here's the list, please edit and add anything I'm missing.

• context.location, context.history
• default hashHistory
• old histories that don't use useRouterHistory
• mixins
• Link props (query, params, etc)
• getComponents first argument
• useRoute (the warning says to use createTransitionManager but I don't think that's right, seems like they should use useRouterHistorybut I don't know the history of that warning, transitionManager seems like implementation, not API)
• isActive(pathname, query, indexOnly) in createTransitionManager and ``replaceState(state, pathname, query)inrunTransitionHooks`
• Multiple leave hooks

After we cut our next minor release (https://github.com/reactjs/react-router/milestones/next-2.3.0), we'll create a 3.0 branch to start working on this stuff, that way we can still make bug fix releases on 2.3 from master. To keep our promise to not make major releases more often than every 3 months, we can release 3.0 on May 9-ish.

[timdorr]

Set up a 2.x branch that we can put stuff on after 3.0 is out. I don't think we need ones for 2.0.x, 2.1.x, 2.2.x, etc.

In order to avoid the hassles and confused issues while we waited on 2.0, we should keep master as 2.x until we're either at or near a 3.0.0 release. It's more annoying for us as developers, but it's also annoying having to close tons of issues because of confusion over docs and code changes.

[taion]

The next major release should go on a rolling next branch (like the one we have). That way you don't have to remember to keep updating .travis.yml (or the Circle equivalent, because Circle is sort of just a lot better) with the branch config.

In practice it's not that confusing to users (since only people close enough to the code to actually follow the repo will see it), and it's less book-keeping for us.

If we're really ambitious, we could just set up the deprecation removals on that branch right now, and cut pre-releases on an ongoing basis.

[timdorr]

Working on that at the moment. Updated the next branch too.

[timdorr]

Re: The getComponents deprecation. That was introduced in 2.2. You guys are closer to this issue than I am, but I remember Ryan (or someone else) saying anything un-deprecated that works in 2.0 will work in 3.0 with warnings. Are we attempting to maintain that here? Honestly, I don't care. I just want to know if it should go into the PR or not.

(P.S. Yes, @taion, CircleCI is many times better than Travis. I've got to talk Dan into using it for Redux. The speedups over there would be quite notable.)

[timdorr]

OK, they're all in #3340.

[timdorr]

Found some more. Added to the OP. But it's bedtime, so if someone else wants to get them, go nuts!

[taion]

@timdorr The rule of thumb is that stuff that people use a lot should stay deprecated for longer. The location arg to getComponent is almost never used, so we don't need to keep it around.

[taion]

BTW, lets go with merging between next and master rather than rebasing. It makes for a slightly messier git history, but it'll be easier to tell what's going on.

[ryanflorence]

@timdorr The rule of thumb

Probably need to document this somewhere.

Rule is: Deprecated API goes away in the next release, unless we decide it's too close to the next release and we want to give people more time.

Sound right @taion ?

[taion]

That makes sense to me.