Guzzle 8 Roadmap / Goals?
Sammyjo20 opened this issue · comments
Hey!
This isn’t really a feature request, more just a conversation I wanted to have around your plans and intentions for Guzzle 8? I see there’a a few open PRs that are related to v8 as well as a few deprecations in the library back from 2020.
Do you have a roadmap yet in place for what’s next for Guzzle (if there is a next version)?
Many thanks for building and maintaining this great package over the years and I’m looking forward to using it more in the future!
I am pretty happy with were Guzzle is at, at the moment, and it is still an effort to get people to even upgrade to Guzzle 7, never mind 8. I am not sure I would even remove all the code currently marked as deprecated in a v8 release - I don't want to create unnecessary friction. The main things I'd like to do in Guzzle 8 would be to enable TLS 1.2 as a minimum by default (an option added in v7.6.0, but currently defaults to 1.0 for BC reasons), and to add HTTP/2 support via the curl adapter, which shouldn't be too much of a lift. Probably dropping support for the old psr7 and promises library would happen in Guzzle 8, too.
Probably more near on the agenda would be a guzzle psr-7 v3 release, with some breaking changes to allow us to pass the psr-7 interop integration tests, and adding parameter types to all the things.
Thanks for getting back to me @GrahamCampbell
From a user side, I really like Guzzle 7 - I really like that you can pass in options on a per-request basis. This allows us to be able to configure timeouts/options on a per-request basis. Do the CURL options work on a per-request basis too? If there are any options that only work on a client level it would be good to know that.
I guess the only suggestion I would have is maybe a face-lift on the documentation side of things. I would recommend something like https://www.gitbook.com/ however that would introduce a third party that is out of your control if they go down. But the documentation is fine as it is - it's clear enough.
With regards to Guzzle PSR-7 v3 what do you mean by "psr-7 interop integration tests"? Are you just referring to a set of tests that the standard requires you to implement? And I guess you mean just adding types to the library?
With a bit of context on my side, I am the creator and maintainer of Saloon, a library that wraps around Guzzle to introduce a standardised object-oriented way to build API integrations. I'm currently working on version three and I'm making it HTTP-client agnostic (but recommending all the users use Guzzle still 😉) so I am just getting a gauge on the roadmap for Guzzle so I can get an idea of any breaking changes in case I lean on them too hard.
As long as you take care to not extend classes or use methods or classes marked as @internal or @deprecated, you should not run into major issues.
Awesome! Thanks Graham :)