-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Tracking breaking changes for v2.0 #2065
Comments
|
Unfortunately we'll likely have to handle them on a case-by-case basis. Potentially we can keep this issue open so we can remember how we handled each and that'll help with writing the migration guide. |
Another breaking change that should be mentioned in the changelog is getheaders() return signature changing. |
Breaking change: |
Breaking change: Removed |
Multipart header parameters now formatted to modern WHATWG HTML standard: #2257 |
We now use towncrier, so I'm going to repurpose that issue to make sure we record all noteworthy v2 changes as news fragments. That way, we won't have to track every change down when we'll actually release 2.0. |
@pquentin Agreed, would you be willing to tackle that? |
Yes, I'm on it! I have 167 commits to review. |
I've added 27 potential news fragments to the first comment. Some of them are already in the news fragments, and some of them may turn out to be irrelevant, but that's easier to work with than the original 167 commits :) |
Should we turn this into a good first issue? Anyone can add a few news fragments, once merged we can mark them as done above. See https://github.com/urllib3/urllib3/tree/main/changelog for the related documentation. Or is this something that we should do ourselves? |
@pquentin We should probably do this ourselves, otherwise it'll be a lot for us to manually review anyways. |
We need to record all noteworthy 2.0 changes as news fragments. Here's the full list: 1.26.x...main. I've listed all relevant changes below. Sorry, this is messy, I sometimes link to the merged commit, and sometimes to the PR. The merged commit is usually a better starting point as Seth usually rewords before merging.
Original issue below.
We just removed two bits of API in 2.x because they're no longer useful in Python 3:
urllib3.contrib.appengine.AppEngineManager
in Drop support for EOL Python 2.7 and 3.5 #2044strict
parameter fromPoolManager
,ConnectionPool
andConnection
(currently used by requests) in Remove strict parameter #2064Should we:
AppEngineManager
an alias ofPoolManager
and accept but ignorestrict
?I think we said we were aiming for zero API breakage of that sort, and @untitaker has mentioned it would help the Sentry SDK. I'd be in favor of option 2.
The text was updated successfully, but these errors were encountered: