[RFC]: Allow better constraint handling for PHP

[dereuromark]

RFC

Goal

Set PHP constraint to normal industry default and recommended setting

Background

Right now CI for many projects and libraries is blocked due to this library:

    - laminas/laminas-diactoros[2.2.2, ..., 2.4.1] require php ^7.1 -> your php version (8.2.0-dev) does not satisfy that requirement.
    - laminas/laminas-diactoros[2.5.0, ..., 2.6.0] require php ^7.3 || ~8.0.0 -> your php version (8.2.0-dev) does not satisfy that requirement.
    - laminas/laminas-diactoros[2.7.0, ..., 2.14.0] require php ^7.3 || ~8.0.0 || ~8.1.0 -> your php version (8.2.0-dev) does not satisfy that requirement.
    - laminas/laminas-diactoros[2.15.0, ..., 2.17.0] require php ^7.4 || ~8.0.0 || ~8.1.0 -> your php version (8.2.0-dev) does not satisfy that requirement.

I also dont see any beta branch to checkout instead to allow CI to check early on if there are any issues with 8.2 RC currently.

Proposal(s)

Set PHP constraint to normal industry default and recommended setting of semver

^7.4 || ^8.0

or even - which everyone normally does -

>=7.4

Any issues that appear theoretically (in beta/RC phase) can easily be fixed way in advance using CI.
Usually, within semver, this is only about deprecations, so no real issue anyway.
And for major issues, people know to use the latest versions then on their own. No need to overdo the constraints here.

OR

As an alternative providing a branch or setup that allows using this library in a less blocking nature.

OR

Already test and finish the 8.2+ support as right now we are in RC phase already for months, github actions can have this job already to check in CI.

[Ocramius]

Dependency ranges CANNOT be un-bounded

Set PHP constraint to normal industry default and recommended setting

Even if PHP were to follow SemVer, a constraint that only defines a lower bound via >= is a clear mistake, as it will cause issues when dependencies are updated in many years to come (on PHP 9, 10, etc.).

In practice, a composer update on a future system running PHP 10 may install laminas/laminas-diactoros:2.18.0 (assuming we'd relax the range there), leading to clear incompatibilities.

The "industry default" is 100% erroneous here.

Regardless if the dependency is PHP or not, please respect SemVer, and only support what you are 100% confident will work. Ranges that support unreleased major versions are bugs.

PHP does not follow semantic versioning

Due to its size/scope, PHP does not follow semantic versioning: pinning to a major PHP version, such as ^8.0, is not viable.

While in the past it may have been acceptable to use ^7.1 (as an example), our experience over the years clearly showed that we need to be strict on supported PHP versions, as otherwise very old libraries land in production, even with wild incompatibility issues.

Many tiny papercuts affect us in each minor PHP release, leading to the usual "death by a thousand cuts" scenario.

We cannot afford to backtrack and apply bugfixes to ancient releases, if they have an open-ended dependency range declared, and incompatibilities with newer versions would be considered bugs, given the clear dependency range declaration there.

How to workaround this limitation?

If you feel brave, and you know precisely what you are doing, you can use either of:

composer update --ignore-platform-req=php+

or

composer update --ignore-platform-reqs

When will PHP 8.2 be supported?

We already prepared our CI to support PHP 8.2:

• Add PHP 8.2 to the list of installable versions laminas-ci-matrix-action#132
• Adds PHP 8.2 + extensions to the container laminas-continuous-integration-action#128
• allow testing of new unstable PHP versions as draft PRs .github#37

What's missing is increasing the dependency ranges, after proving that CI runs are green with those ranges applied.

Pre-existing decision

This versioning scheme was agreed upon by the Laminas TSC.

I can't find the exact notes, but see https://github.com/laminas/technical-steering-committee/tree/450730345658dab54003efff8e8e38206aa70da2/meetings/minutes

[weierophinney]

@dereuromark Another way of putting this is: we cannot say that the component runs on a new minor or major version of PHP without first proving it passes tests. Having our constraints more strict ensures that we deliberately bump the constraints for new PHP versions via a patch in order to verify that tests pass in our CI.

This actually protects you the consumer.

In the past, when we had more liberal constraints, consumers would install the library in a new PHP version, run into issues, and open tickets to report them. This meant we were reactively fixing them, and as fast as possible, as we were now breaking a deployed application; it also meant we often didn't see all the potential issues immediately, leading to a scattershot of bugfix releases.

With the approach we've adopted, if you can install the library on a given PHP version, you can be assured it has actually been tested on that version, and that you should not run into compatibility issues.