Announcing the upcoming deprecation of PHP runtimes 8.0.x and below

[stobrien89]

On January 13, 2025, in order to continue supporting our customers with tools that are secure and maintainable, AWS will publish a minor version bump of the SDK, which will formally end support for PHP runtimes 8.0.x and below.

The PHP Group has deprecated PHP 8.0 as of November 30th, 2023, which means no new bug reports, fixes, or changes will be made to PHP 8.0. Many widely-used PHP projects and packages have discontinued support for PHP versions below 8.0, and we will be joining these deprecations to maintain a secure and up-to-date SDK.

I use a PHP language level below 8.0. What should I do?
For users below 8.0.x, we recommend updating your PHP language version to a language version supported by the SDK, if possible. Versions of the SDK published early-mid August 2024 through January 13th, 2025 will emit a warning on client construction that your PHP version will be deprecated soon. This can be turned off by setting suppress_php_deprecation_warning to true in your client constructor, or globally by setting the AWS_SUPPRESS_PHP_DEPRECATION_WARNING environment variable to true.

What if I can’t upgrade to PHP 8.1 or higher?
In the event that you’re unable to migrate to PHP 8.1 or higher, previous versions of the AWS SDK for PHP will continue to operate after the deprecation date. Depending on your installation method, you will either stop receiving updates after the deprecation date, or will need to download a release that is compatible with your PHP version.

I use a PHP language level of 8.1 or higher. What should I do?
If you already use a version with continued support, no action is required. You are not impacted by this announcement.

Conclusion
If you’re currently using PHP versions 8.0.x or below with the SDK, we encourage you to upgrade to PHP 8.1 or above. Please share your questions, comments, or concerns with us in a direct reply to this issue.

Links

https://aws.amazon.com/blogs/developer/announcing-the-end-of-support-for-php-runtimes-8-0-x-and-below-in-the-aws-sdk-for-php/

[stobrien89]

Hi @ishiguro-junya,

The call wasn't intended to trigger an exception, but it may if you're using a custom error handler (depending on how you've configured it). If you want to suppress these warnings, just add 'suppress_php_deprecation_warning' => true to your client constructor, or set the AWS_SUPPRESS_PHP_DEPRECATION_WARNING environment variable to true

[ishiguro-junya]

@stobrien89
I'm not very familiar with PHP, so I'm sorry if I'm saying something off-topic.

I believe that the following settings in php.ini are generally considered standard for production environments.

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

But, with this setting, I think that the combination of trigger_error and E_USER_WARNINGE_USER_DEPRECATED will be handled as an exception in Larabel's handleError function.
https://github.com/laravel/framework/blob/7e82e1a272a72d75b4cd7f35a2267e9af5d642c2/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php#L66-L71

I can't tell at my level whether it's the Larabel implementation that's bad or the error output that's bad, but is it okay?

Of course,
if you set AWS_SUPPRESS_PHP_DEPRECATION_WARNING=true or are using PHP 8, there is no problem,
but in old Laravel environments using PHP 7, an exception will occur if you do not fix the package version, and I thought that you might be affected like me.
It is my fault for using the old PHP 7, but I wanted to share that there are cases like that.

[Danny-Smart]

Can you change this to raise an E_USER_DEPRECATED instead of an E_USER_WARNING please?

[ishiguro-junya]

@Danny-Smart
Is this what you mean?
https://github.com/aws/aws-sdk-php/pull/2989/files

The error is the same as this one, but the log level is E_USER_DEPRECATED, so maybe it was a mistake.

aws-sdk-php/src/AwsClient.php

Line 704 in afe137e

E_USER_DEPRECATED

[Danny-Smart]

Yeah pretty much. It's a notice of deprecation, so it should be E_USER_DEPRECATED

[stobrien89]

Hi all,

The decision to set the error level to E_USER_WARNING was a conscious one. This is not a deprecation in the classic sense— users can continue using older PHP versions with SDK versions published prior to the language level bump. They just won't be able to upgrade to SDK versions published after the language level bump. Because E_USER_DEPRECATED is a higher warning level than E_USER_WARNING, we opted for something we thought might be less disruptive.

That said, if it would helpful to the majority of users to change this to E_USER_DEPRECATED, this is something we could reconsider.

[Danny-Smart]

I'd actually consider this more disruptive as a warning. E_USER_DEPRECATED is typically found in development and filtered out in production. Warnings are runtime events that you ought to know about in production in case they signify an issue and so are frequently not filtered (it will vary between teams, but all the applications I've worked on have logged warnings in production) .

Having this as a warning could potentially spam production logs and hide other issues, if a developer wasn't looking closely enough during development

[stobrien89]

Between your and @ishiguro-junya's feedback, I think we can justify changing this. Initially I closed @ishiguro-junya's PR, but I've reopened it and fixed up the tests. Unfortunately we won't be able to release this until next week.

[ishiguro-junya]

@stobrien89
Thank you for considering the correction.
This was a good learning experience for me.

[stobrien89]

Thanks for your patience everyone. @ishiguro-junya's changes are live in today's release. Please let us know if you have any other questions or issues.

[Danny-Smart]

Thank you 😄

[mreschke]

I just deployed one of our main data ingestion projects today, which has worked for 10 years and is deployed at least monthly...and because of laravels dependency on awk-sdk-php "~3.0" it pulled in your latest 3.320.9 which completely broke the entire system because after 3.319.* it requires PHP 8. This is a major backwards compatibility break which you maybe should have bumped to a 4.0.x? Doesn't feel like symver was followed here? After many hours of production breakage, I have now pined to "3.319.*" to solve this symver overlook.

[ishiguro-junya]

@mreschke
I think your opinion is valid.
Our Laravel project started crashing during our daily deployment after we ran composer install and upgraded the SDK version.

Due to concerns about system availability, I had to freeze the SDK version at 3.319.4, which was before this warning was emitted.

3.319.4...3.320.1

[ishiguro-junya]

After listening to @mreschke's opinion,
I think that these warnings should be added at the timing of release January 13, 2025 & major version upgrade to 4.

What do you think @stobrien89 ?

[fredericgboutin-yapla]

Watch out, kicking a new major could trigger a massive chain reaction with all the other components depending on this package as it would need them to change their dependency requirement towards AWS SDK to explicitly add support for v4 even though there is no API change.

See https://packagist.org/packages/aws/aws-sdk-php/dependents?order_by=downloads

For example, even though I update my own code to support v4, I might be unable to use the v4 until all my dependencies updated their support as well.

[stobrien89]

@mreschke,

Apologies for the disruption. To be clear, we didn't drop support for PHP versions below 8.1 (yet)— the deprecation warning you're seeing is advance notice of a deprecation campaign we're running for PHP versions 8.0.x and below. We won't actually change our PHP version requirements until 1/13/2025.

@ishiguro-junya, The reason we're starting to emit these runtime warnings now is to allow users in the affected version ranges to upgrade their PHP runtime if they wish to do so.

In any case, you can opt out of these warnings by setting the suppress_php_deprecation_warning client config or AWS_SUPPRESS_PHP_DEPRECATION_WARNING to true.

[stobrien89]

Regarding the major version bump,

Because we are simply dropping support for EOL PHP runtimes and not introducing new core functionality, we will not be releasing a new major version of the SDK. A more in-depth explanation of our approach to versioning can be found here

[Danny-Smart]

@mreschke, I would also consider an upgrade of PHP version to be a breaking change, but I think it's more important to call out that the AWS SDK doesn't use Semver.

Semver considers any breaking change to require a new major version, but the documentation states:

Increasing the major version of an SDK indicates that this SDK underwent significant and substantial changes to support new idioms and patterns in the language

So we should expect unsubstantial breaking changes to be released in minor or patch versions. e.g. not following Semver.

[stobrien89]

@mreschke, @Danny-Smart,

I think it's worth pointing out that while we don't adhere to Semver guidelines (we hope to at some point in the future), in most cases, this change will prevent users running PHP versions 8.0.x and below from upgrading to SDK versions released on and after January 13, 2025. SDK versions published prior to that date will continue to work as they did before.

[Danny-Smart]

@stobrien89

we hope to at some point in the future

Don't. Semver is broken.

I personally use Ferver, but what you have now is fine. It's just important that people don't get the wrong idea