cloudflare-php

cloudflare-php copied to clipboard

Please update guzzlehttp/guzzle to version 7.

Thank you in advance.

Guzzle 7 requires a minimal version of php:^7.2.5 which may reduce the compatibility of this library which currently supports php:>=7.0

Do we have any policy around what is the minimum supported version of PHP? @IcyApril

@haphan https://www.php.net/supported-versions.php

As the guzzle7 PR was merged, is there any ETA on when a new release will be tagged?

Also curious when a release will be made, this is the only package keeping me from updating my project.

@IcyApril Can we get a release tagged so we can use the merged Guzzle 7 PR? Thanks!

I think we can temporarily install the package from the master branch to use the merged Guzzle 7 PR.

composer require cloudflare/sdk:dev-master

I think we can temporarily install the package from the master branch to use the merged Guzzle 7 PR.

composer require cloudflare/sdk:dev-master

I would lock it on the commit hash for now

"cloudflare/sdk": "dev-master#7db3d6e62c7ab8fa29780354e8d370c49939cdec",

This is like 2 months old now, when will Guzzle 7 be tagged? Just do a major version update for it. 1.2.x or 2.x or however you want.

Does no one at Cloudflare use this package at all? If you put yourself through your customer/user pain points, things get done a lot faster... 😞

@IcyApril Any idea what's going on? How can we (the community) help?

Does no one at Cloudflare use this package at all? If you put yourself through your customer/user pain points, things get done a lot faster... 😞

https://www.parkersoftware.com/blog/are-you-eating-your-own-dog-food/

Any update as to when the new version will be tagged?

This should be closed as they have released 1.1.7 with Guzzle 7, although I believe this should have been at least 1.2 but ideally, 2.0 as this does break if we have other packages relying on Guzzle 6.

Complete lack of feedback from maintainers is really disappointing.

While, off course , depending on a newer Guzzle version is a good thing for the project, making it user friendly way is completely possible and a preferred. As was previously suggested, that could be done in two ways:

1. releasing v2 of the package
2. allowing both versions to co-exist with ^6.0 || ^7.0 version constraint in 1.x release

On behalf of community and users of this project I'm asking maintainers to update version constraint to ^6.0 || ^7.0 and release new version for 1.x branch.