Replace legacy polyfills, unbound php upper bound

[nicolas-grekas]

I suggest the following patch to composer.json:

Unlocking the upper bound of PHP to give back control to end users about where they want to run the tool.
Replacing some polyfills that don't need to be installed, but would be otherwise.

--- a/composer.json
+++ b/composer.json
@@ -26,7 +26,7 @@
         }
     ],
     "require": {
-        "php": "8.1.*||8.2.*||8.3.*",
+        "php": ">=8.1",
         "ext-zip": "*",
         "composer/composer": "dev-main@dev",
         "guzzlehttp/guzzle": "^7.8",
@@ -44,6 +44,11 @@
         "psalm/plugin-phpunit": "^0.18.4",
         "vimeo/psalm": "^5.22"
     },
+    "replace": {
+        "symfony/polyfill-php81": "*",
+        "symfony/polyfill-php80": "*",
+        "symfony/polyfill-php73": "*"
+    },
     "config": {
         "sort-packages": true,
         "preferred-install": "dist",

[asgrim]

We cannot claim to support PHP 8.4 yet (that is work in progress still - see #32), so this is a no-go really; it does not exist in its final form yet yet, so we cannot possibly claim support for it. If people want to test it without explicit support, it is already possible to use composer install --ignore-platform-req=php+

[nicolas-grekas]

As long as bug fixes are released for PHP 8.4, the declaration would still be correct.
Any OSS license explains that the software is provided "as is", without even any promise of a purpose.
A composer.json file is not the place for more restrictive claims.

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

yes, that's a workaround though, around authors that have too restrictive policies ;)

Note that while writing this comment, I realized that this repo has no license terms anywhere.
Something to fix I suppose.

[asgrim]

As long as bug fixes are released for PHP 8.4, the declaration would still be correct.

And until such time, the declaration is wrong, and all current releases are possible to install but actually be broken, with no way of retrospectively fixing those already released versions in the wild (short of deleting the tags or other destructive methods). For example: a breaking change in PHP 9.0 for example may cause all older versions to stop working for some reason; if you subsequently exclude PHP 9 from a later release due to needing extensive changes to support a new PHP version, it doesn't matter - the already released versions make a claim they are compatible with PHP 9.0, but they are not, in actual fact.

Any OSS license explains that the software is provided "as is", without even any promise of a purpose.

Quite - and I would use this same point to encourage those who want to use it in ways they want to to use:

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

as already proposed.

yes, that's a workaround though, around authors that have too restrictive policies ;)

The restrictive policy is intentional; dependencies maybe declared on a project to claim compatibility, with at least some vague consensus/expectation that the author(s) have actually tested the software with the dependencies claimed. A library who claims they are compatible with unreleased future versions (such as PHP 9.0 or beyond) cannot possibly be guaranteeing that.

One middle ground perhaps, is to use the semver token (i.e. ^8.1); and whilst PHP itself does not actually use semver, would go half way in solving the above issues resulting from "major" changes in the language; which typically PHP itself tries to reserve for major version bumps (I like to think of it as semver-"ish"). I would settle for ^8.1 as a middle ground (even though I have seen issues with even this style of declaration in libraries, as it is extremely common), but I think it is dangerous to claim compatibility with ALL possible future versions of PHP ever.

Note that while writing this comment, I realized that this repo has no license terms anywhere. Something to fix I suppose.

That is a very good point, and I shall raise a separate discussion about which license (I'd assume it would be PHP 3.01, but will check). Update: see #52 for that

[brzuchal]

Why not ^8.1 || ^8.2 || ^8.3? This allows 8.4 but doesn't directly commit to support for 8.4 if I am not wrong.
This way 9.0 is not accepted by default.