Switch static-php-cli to support PHP 8.3 and 8.4 only

[crazywhalecc]

What does this PR do?

Switch static-php-cli to support 8.3 and 8.4 only.

The reasons for this are:

• static-php-cli is not a library type, so there is no need to consider compatibility with a wide range of PHP runtimes.
• static-php-cli provides a standalone binary spc that does not require a PHP environment.
• There may be Composer dependency conflicts under multiple PHP versions, which will increase the maintenance cost of static-php.
• The PHP version required by static-php-cli does not conflict with the PHP version that static-php-cli supports compilation.
• Although we switch all workflows to PHP 8.4 only, but we still support PHP 8.3, this can reduce the trouble caused by not being able to install PHP 8.4 under common distributions (Ubuntu, Alpine, etc).

cc @DubbleClick

Checklist before merging

If your PR involves the changes mentioned below and completed the action, please tick the corresponding option.
If a modification is not involved, please skip it directly.

• If it's an extension or dependency update, make sure adding related extensions in src/global/test-extensions.php.
• If you changed the behavior of static-php-cli, update docs in ./docs/.
• If you updated config/xxx.json content, run bin/spc dev:sort-config xxx.

[crazywhalecc]

At present, at least common distributions (Ubuntu, Alpine, Fedora) cannot directly install PHP8.4 through package management. Reducing it to 8.3~8.4 may be a compromise solution.

[henderkes]

RHEL still installs 8.0 by default and doesn't have 8.2+ in the main rpm repo. I don't think we need to shackle ourselves to ancient versions just because users will have to enable extra modules in one command.

You've said it yourself, SPC is not a library. The only people this change should concern are developers who are working on SPC.

[crazywhalecc]

RHEL still installs 8.0 by default and doesn't have 8.2+ in the main rpm repo. I don't think we need to shackle ourselves to ancient versions just because users will have to enable extra modules in one command.

That's true. But I still think that the restrictions in composer.json should not be too strict. We have already fully used and required the latest version in the documentation, workflow and setup-runtime, and there is almost no essential difference between 8.3 and 8.4.

[henderkes]

and there is almost no essential difference between 8.3 and 8.4.

Technically true, but allowing php 8.3 will require us to stay at 8.3 level in the code and doesn't provide any real benefit. Who benefits from 8.3 support? Are there any developers working on this project who must use their systems php version and cannot update it to 8.4?

The only people this would possibly concern are people who use the main branch of this project in one of their deployment routines. Which is a bad idea, so that's not something we should consider.

In the end, it's up to you. If you believe that there are developers contributing to SPC who cannot install php 8.4, but 8.3, then keep support for it.

[crazywhalecc]

I know this is a rather inconsistent decision, but I don't want to cause a version upgrade to break the workflow of most downstream projects.

One of my private project, FrankenPHP, Herd, and some project forks etc. seem to be built using 8.3. If it is forced to limit to 8.4, related projects will also need to update the compilation script immediately, or completely use spc binary for building.

For PHP 8.3, I think the following measures can be taken to gradually transition:

• Prompt the version that is about to be deprecated at startup
• Create a Pull Request for downstream updates at the same time
• Write the upcoming breaking changes in the update log (for spc source mode)

[henderkes]

FrankenPHP, Herd, and some project forks etc. seem to be built using 8.3. If it is forced to limit to 8.4, related projects will also need to update the compilation script immediately, or completely use spc binary for building.

Yes and no at the same time. They all require specific commits of this repository, so nothing would change immediately. They would continue to work just fine. Only when they update the SPC tag they use, they would also have to update their jobs from 8.3 to 8.4.

Prompt the version that is about to be deprecated at startup

Yes, that's a good idea.

Create a Pull Request for downstream updates at the same time

I don't think that's reasonable. We don't know all the downstream project and we don't know when they even plan to update the SPC release they use.

Write the upcoming breaking changes in the update log (for spc source mode)

Good idea.

[crazywhalecc]

Updated spc-alpine-docker and added deprecate notice. After the PR is merged, the gnu static branch needs to be updated synchronously.