Support 8.0 and 8.2

[eerison]

Support 8.0 and 8.2

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

Hey guys would be possible we create a release that supports php 8.0 and 8.2?
atm I am doing upgrade from 8.0 to 8.2 and it is the only lib that isn't compatible with both php versions :/

edit: maybe on 4.8.x: https://github.com/laminas/laminas-code/blob/4.8.x/composer.json#L12

[Ocramius]

PHP 8.0 is no longer supported at all: it's out of maintenance since end of 2023.

https://www.php.net/supported-versions.php

[eerison]

Hey @Ocramius

I know it is not maintained anymore, But there isn't a version that support php 8.0 and 8.2, it keeps the php upgrade a bit more complicated 😞

I really appreciate if we could add a patch for 4.8.x supporting 8.0 version like

-"php": "~8.1.0 || ~8.2.0"
+"php": "~8.0.0 || ~8.1.0 || ~8.2.0"

if you want, I could open a PR for this.
if not no problem, I understand that project don't want invest effort on non-maintained php version.

Note: I would like this 4.8.1 version just to make php upgrade from 8.0 to 8.2 smoothly.

[Ocramius]

@eerison you don't need to pin to a specific laminas/laminas-code version: if you rely just on basic stuff, ^4 should suffice for you.

[eerison]

But it gonna generate 2 different composer.lock.
And I need to keep 8.0 and 8.2 support for a while, because we need to test it.

And it's the only dependency that doesn't support

8.0 || 8.2 🥲.

Making this change here, I would have the same code base and dependencies version working on 8.0 and 8.2.

[Ocramius]

But it gonna generate 2 different composer.lock.

Indeed, that's exactly what it will end up with, and that is OK :-)

Otherwise, lock your dependencies for only one specific version (probably your lowest supported one), and test with lowest and latest all other versions.

That's precisely what our CI does here as well:

• run tooling (test, code style, static analysis, etc) with locked dependencies at one specific version
• test (only) lowest/latest with all other versions

https://github.com/laminas/laminas-code/actions/runs/8297214672/job/22707845493

[eerison]

Indeed, that's exactly what it will end up with, and that is OK :-)

Yep, I just would like to avoid

• handle 2 composer.lock
• care about switch php version on instances only
• and avoid get conflicts in case some dev run composer update in our project.

it is the output that , I get when I try to run composer install without run composer update(on 8.2).

Your lock file does not contain a compatible set of packages. Please run composer update.

  Problem 1
    - laminas/laminas-code is locked to version 4.7.1 and an update of this package was not requested.
    - laminas/laminas-code 4.7.1 requires php >=7.4, <8.2 -> your php version (8.2.5) does not satisfy that requirement.
  Problem 2
    - laminas/laminas-code 4.7.1 requires php >=7.4, <8.2 -> your php version (8.2.5) does not satisfy that requirement.
    - friendsofphp/proxy-manager-lts v1.0.18 requires laminas/laminas-code ~3.4.1|^4.0 -> satisfiable by laminas/laminas-code[4.7.1].
    - friendsofphp/proxy-manager-lts is locked to version v1.0.18 and an update of this package was not requested.

[Ocramius]

Few things to note:

Laminas PHP version support

Laminas drops support for EOL versions of PHP as they go EOL.

This is decided here.

It will be done regularly / whenever we touch projects.

Don't add feature work to old branches

We don't touch past releases unless it's a critical or security bugfix.

Especially don't want to touch composer.json for older releases: that brings tons of permutations of external complexity in a patch version update, and you don't want this to happen for people upgrading patch releases.

What if we still applied a version support widening patch?

Even if we applied a range widening patch to an older release, you'd run in the same problem at the next minor PHP version anyway.

With PHP 8.4, for example, we'd probably drop PHP 8.1, which is planned to be supported until 2026-01-01.

Single composer.lock is unobtainable

A single composer.lock for multiple PHP versions is not really realistic: you'll run in tons of edge cases anyway, and you should decide which version your "mainline" one is.

From a lock-file perspective, consider locking all your dependencies, not only the PHP ones (see flake.lock, for example).

Besides that, PHP's breaking-changes-in-every-minor-release leads to the ecosystem adjusting/bumping dependency ranges regularly (and healthily so), so you'd end up playing whack-a-mole anyway. This is not a Laminas issue, but a general ecosystem direction :-)

My endorsement

• use composer install on your designated minimum supported PHP version
• use composer update --prefer-lowest and composer update on all newer PHP versions you want to support

[eerison]

No problem, thank you for the explanation.