Limit to major releases rather than second point.

requests should trust dependent packages to do semver rather than artificially limiting version compatibility, which causes problems for pip.

Fixes https://github.com/psf/requests/issues/5341, https://github.com/psf/requests/issues/5337 and supercedes https://github.com/psf/requests/pull/5226.

Thanks for the patch, @cjw296! I'm a bit torn on this one. I agree that logistically this is a painful process for all parties involved. A minor version bump *should* be backwards compatible, but inevitably, that rule will be broken. The question comes down to how should a library used in a number of pieces of critical infrastructure handle that case?

We've had a lot of discussion on this in #4673 (Reasoning: [1](https://github.com/psf/requests/issues/4673#issuecomment-395069592), [2](https://github.com/psf/requests/issues/4673#issuecomment-395449858)). The specifics of that ticket are for urllib3, but it applies similarly to chardet and idna. The short of it being we'd rather be explicit on what we support in the event issues arise. The way pip handles conflicting dependencies makes this case more complicated, but that's unfortunately the environment we're currently in.

I'm happy to have the discussion again if we've got opinions from Seth or others on the Requests team.



@sethmlarson seems in agreement with what I've suggested, and I didn't realise how intertwined the `urllib3` usage was, so what you've both said makes sense. Would you be amenable to merge and release if I rebase, and change the `urllib3` spec to the one I suggest above?

chardet is pretty stable and dormant now, so I'm not so concerned about that pin. idna is kind of an unknown. It's probably safe, I'm just not excited on having to do an emergency release to pin it in the future after any potential damage has already been done.

If Seth wants to approve and merge, I'm ok with it once the urllib3 pins are reverted.

To be clear: I've had to do emergency releases of at least three packages as a result of this pin and the idna release. It's a risk call for you, the requests maintainers: do you want to do emergency releases of requests on every new release of a dependency, or do you want to do an emergency release under the, hopefully rare, circumstances that a dependency doesn't do semver right.

@sethmlarson - over to you :-)

Just to add weight to @cjw296 I have also had to take emergency action as a result of the idna release and requests pinning it to a minor version.

From my perspective the risk of a minor release being breaking is valid but hopefully low. Though I completely acknowledge that it must be frustrating for the requests maintainers to have to resolve it with an emergency release when it inevitably happens. 

However debugging the issues caused today by the idna release, because requests has pinned a minor version, has been unpleasant. One specific example is that a package I maintain does not depend on requests, but a dependency does. Another dependency has idna as a dependency but is pinned on major versions. It seems pip was unable to resolve this dependency graph correctly and pulled in 2.9, breaking requests, the dependency of my package and therefore the whole package. Adding requests as a dependency to my package and pinning to `<2.9` has resolved it and resulted in an emergency release. 

This has been frustrating to untangle and has fallen on those that depend on requests to resolve.

Yep, I'll work on getting a cleaned up release out today or tomorrow.