Dual-venue record for GitHub #80. Filed so the floor is a decision on record rather than drift.
composer.json declares "php": ">=8.3". That is true for two independent reasons, either sufficient on its own:
drupal/simple_oauth ^6.1 is a runtime requirement. It pulls league/oauth2-server and lcobucci/jwt, both declaring php: ~8.2.0 || ~8.3.0 || ~8.4.0 || ~8.5.0. PHP 8.1 cannot resolve at all.public const string NAME = …) in six places across four files. That is PHP 8.3 syntax; below 8.3 it is a parse error.So the choice is 8.2 versus 8.3, not 8.1 versus 8.3. It was previously recorded as though it were the latter, which made it look like a CI-convenience narrowing. It is not.
Stay at >=8.3. Revisit only if a real Drupal 10.6 + PHP 8.2 user turns up.
Widening to 8.2 would mean dropping the string type from six class constants (mechanical, no behaviour change) and adding a Drupal 10.6 + PHP 8.2 CI leg, since a support claim CI does not exercise is not a claim. It would also be a partial claim on that leg: drupal/mcp_server is in require-dev and needs PHP ^8.3, so the server submodule's suite cannot run on 8.2 at any 2.x version.
Only Drupal 10.6 sites on PHP 8.2 would benefit — Drupal 11.3, this module's D11 floor, requires 8.3 regardless. That window is narrow and closing: PHP 8.2 leaves security support 2026-12-31 and Drupal 10.6 goes EOL 2026-12-16, so the combination expires almost simultaneously.
None unless the decision is revisited. Recorded here so the reasoning is findable rather than re-derived.
Comments
Comment #2
jmcerdaClosing: the decision is recorded and there is nothing to build.
**The floor stays at `>=8.3`.** It is what the code requires, for two independent reasons either of which is sufficient on its own — `drupal/simple_oauth ^6.1` is a runtime dependency whose chain cannot resolve below 8.2, and the module's typed class constants are a parse error below 8.3.
Reaching 8.2 would help only Drupal 10.6 sites on PHP 8.2; Drupal 11.3, this module's D11 floor, requires 8.3 regardless. That window closes almost immediately — PHP 8.2 leaves security support 2026-12-31 and Drupal 10.6 goes EOL 2026-12-16 — and the claim would be partial anyway, since a require-dev dependency needs ^8.3 and one submodule's suite could not run there.
Deliberately not closed as "too much work": it is about an hour. Closed because the beneficiary set is nearly empty and expiring, and recommending a security-governance module run on a PHP nearing end of security support is its own problem.
Reopen if a real 10.6 + PHP 8.2 user appears.