Add support for Guzzle 8#3294
Conversation
|
Thanks for the work on this @GrahamCampbell. When is the release date for 8? |
|
I did the 7.11.0 release today, along with 6 releases in the other first-party packages with a bunch of deprecations. I'll see how that goes with feedback, and I'll be doing more evaluation of the upgrading of the most popular packages to Guzzle 8. I don't yet have a an exact release date to share. I am hoping it'll be ready early Q3. |
9e054a2 to
1dd0756
Compare
90e0fd2 to
8b55587
Compare
|
Guzzle 8 has now been released, and this PR is ready for review. :) |
|
There is actually a further deprecation introduced in Guzzle 7.15.0, which I extracted to a separate PR if we want to merge that one first: #3327. |
07c68a0 to
7c15ba9
Compare
|
Rebased on master master. Ready for the final review. ☕ |
|
@GrahamCampbell working on those test failures now. I'll add another commit when done |
Guzzle 8 is not yet released, but once it is, getting support in the AWS SDK is important, because it would otherwise block many other projects including Laravel from supporting Guzzle 8.
#3289 already makes a forward-compatible change that makes the SDK compatible with Guzzle 8's stricter requirement that headers be strings or lists of strings. The next change to be aware of is Guzzle 8's changes to the exceptions. The
ResponseTransferExceptionexception was added specifically to accommodate the needs of the AWS SDK to want to retry this sub-class of failures, without needing to look at the handler context which is a leaky abstraction that was removed in Guzzle 8.This PR makes changes to support the old and new exception design, and adjusts version constraints to support both Guzzle 7 and Guzzle 8. By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.