Require PHP 8.4

[greg0ire]

No description provided.

[greg0ire]

I do not see a breaking change here, so let's target 2.1.x?

[SenseException]

I guess so.

[Skaronator]

Hi there! I just attempted to update from 2.0.0 to 2.1.0 and noticed my builds are failing because I am currently running PHP 8.3, and this release dropped support for it.

Since this is a minor release (2.1.0), SemVer suggests it should remain backward compatible with the environments supported in 2.0.0. By restricting the requirement to ^8.4, this acts as a breaking change for anyone not yet on the newer PHP versions.

Could we potentially widen the constraints back to ^8.2 for the 2.x release line? PHP 8.2 is still officially supported for another 11 months, and PHP 8.3 is even newer, so dropping support for both in a minor release seems quite aggressive.

Alternatively, if dropping support is intentional, should this have been tagged as a Major release (v3.0.0)?

Thanks for your work on the library!

[greg0ire]

A breaking change happens when you upgrade, and things break. But here, you cannot upgrade.

From semver.org itself

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. We would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

The real question is: why do you need to upgrade? To make sure you keep receive patches? Because the last patch was released late 2022…

[derrabus]

Hi there! I just attempted to update from 2.0.0 to 2.1.0 and noticed my builds are failing because I am currently running PHP 8.3, and this release dropped support for it.

If you're on PHP 8.3, Composer should not allow you to upgrade. This is a problem on your side.

[Skaronator]

Hi, thank you both for the very quick response.

If you're on PHP 8.3, Composer should not allow you to upgrade. This is a problem on your side.

Yeah you're correct. Sorry for bringing this up in this closed PR. The root issue is that Renovate doesn't know which PHP Version we're targeting and it just see a minor update and upgrades it and since this is just a peer dependency it just does that in a regular lockfile maintainance task.

The real fix is to configure constraints.php in Renovate (renovatebot/renovate#13637 (comment)).

I made the mistake while debugging it locally, that composer auto-discovery my PHP Version which is 8.4 but our project targets 8.3 and 8.4, resulting in a even broker lockfile.

Have a wonderful day :)

[MikeRich88]

Is it just me, or does this PR's only substantive change in the code, changing two uses of private const to private const string, seem to have been made for no reason other than to justify this arbitrary PHP version requirement?

[greg0ire]

It's just you. I'm preparing the next major releases of Doctrine, which will require PHP 8.4, and I figured for this one package, there was no breaking change when doing so, like e.g. breaking signature changes. What is your issue with that?