Thank you@jderusse.

This should be reverted: just use ProxyManager 2.5, which is perfectly compatible with 2.4 and previous releases.

we cannot. ProxyManager 2.5.0 requires PHP^7.4. So if your lock file needs to support both 7.3 and 7.4, you are out of luck (btw, unmaintaining all versions compatible with released PHP versions looks bad to me).

@stof2.2.x is still being maintained. Besides that, you lock onto"ocramius/proxy-manager": "^2.0" (or whichever minimum you want) and that's the end of the story.

And no, you don't use onecomposer.lock for multiple environments: that's an upfront thought mistake.

then, please, mergeOcramius/ProxyManager#484

That's already fixed in 2.5.0, which is stable and targets 7.4.

2.2.x is only getting relevant fixes that block folks on 7.3 or lower: using 2.5.0 is perfectly viable for anybody running 7.4, and already contains relevant refactoring and fixes.

nothing prevents <2.5 to be installed with 7.4. Running symfony's test suite withprefer-lowest take a bad version

prefer-lowest takes the appropriate version. Please refrain from using bad/wrong/must/mistake/don't/etc words as that doesn't help. The issue is that we have conflicting versioning practices. Accepting that is the only way to solve the issue. Technically, we have no other alternative here, and although I would also considerOcramius/ProxyManager#484 is the correct way to go, I respect Marco's opinion.
Sorry about the composer warning but that's a false positive.

nothing prevents <2.5 to be installed with 7.4. Running symfony's test suite with prefer-lowest take a bad version

Yes, which indeed is an actual bug: anything below2.5 should have a hard lock on<7.4, but that's not fixable anymore.

Adding support for new PHP versions is a feature addition, and only goes to minor releases anyway.

In general, Symfony's point of view oncomposer.lock is nonsensical to me, if this is an official stance.

prefer-lowest is not applicable due to PHP not supporting SemVer, and pre-existing ProxyManager releases locking onto a too wide range of PHP releases.

I can probably send patches to lock the stable releases of ProxyManager onto smaller ranges of PHP versions, and then you can bump to those versions here, which should be done anyway (new releases for new software: don't expect bugfixes on old releases unless BC breaks prevent an upgrade).

prefer-lowest is not applicable due to PHP not supporting SemVer, and pre-existing ProxyManager releases locking onto a too wide range of PHP releases.

then, why using a semver operator for your PHP constraint if you consider than semver does not apply there ?

Hmm, no, I just checked, and this would simply not work: you need the newest stable dependency when working on 7.4, due to PHP breaking BC. In general, going back and retrofitting stricter dependency ranges is not possible for the grand majority of PHP components, so I suggest restricting the"ocramius/proxy-manager" dependency supported range as much as possible, and not allowing--prefer-lowest for7.4.

then, why using a semver operator for your PHP constraint if you consider than semver does not apply there ?

Mostly legacy: I will gladly accept a patch that locks to"php": "7.4.*" in that repository (as well as any other repo I maintain: I already do inroave/better-reflection), but it is not fixable on already released versions, and won't be fixed either.

Adding support for new PHP versions is a feature addition, and only goes to minor releases anyway.

That's precisely the point where we disagree: the policy of Symfony is to provide support for newer PHP versions as bug fixes. That's the case since many years and it works very well for the community, allowing smoother transitions.

That's cool: I disagree with that, and also with the idea of pushing this amount of overhead and reported issues to your dependencies.

If you want to support new software with oldstable releases, then please do so without interfering with the package ecosystem.

Even easier: add"php": "<7.4" tosymfony/symfony on3.4.x and you will be fine 👍

I'm supposed to do it (and will do it) on my packages anyway, not sure why it shouldn't happen here too.

If I understand correctly if you use a lock file for PHP 7.3 (or 7.2) you cannot install this on PHP 7.4 due to a compatibility issue in PHP 7.4?

This seems like an edge-case to me, you should ensure that your PHP version in production equals that of your development system. Especially when you use a lock file.

Otherwise you can update only theocramius/proxy-manager package when using a newer version? Personally I would expect more issues like these, when installing a lock for PHP 7.3 on 7.4 as many things changed.

@sstok no, the issue is:ocramius/proxy-manager version2.4.x may be chosen by composer will runing 7.4 no matter the .lock file
ie. when user defineocramius/proxy-manager: ~2.4.0 or when user use a dependency that have a constraintocramius/proxy-manager: <2.5 or when symfony run tests with the lowest version of dependencies or for whatever reason.

The root issue isocramius/proxy-manager: <2.5.0 is not compatible with php 7.4 (and will never be from the point of view of the maintainers (which I respect)) will it composer.json allows that version.

Ocramius/ProxyManager#492 should fix the issue and this PR may be reverted.

I can't (and please don't even think about doing it, if you are reading this!) re-tag anything, so a--prefer-lowest will always land onto something incompatible with"php": "7.4.0".

what's about tagging a2.2.4 (or the lowest maintained minor version) with the bug fix updating the composer.json withphp: <7.4
then, symfony may use^2.2.4 to fix this.

did I missed a point?

Yes, very much feasible, but you'd still get2.3.0 and2.4.0, which aren't containing those fixes either ;-)

well, we would need a fixed patch release for each minor version. then we can build a requirement for that.

I can most certainly fix ranges that way 👍

2.3 and 2.4 require 7.4 (https://github.com/Ocramius/ProxyManager/blob/2.3.1/composer.json) adding a constraint< 7.4 does not make sense.

They should either be fixed with@nicolas-grekas patch or totally excluded.

They'd probably have to be excluded then, which is also fine.

@Ocramius couldn't you just tag new patch releases of both the 2.2, 2.3 and 2.4 line? Then the ^ constraint should work fine, no matter which feature line composer resolves to.

It wouldn't help, because the SAT mechanism would still resolve2.4.0 even if I tagged2.4.1 with a PHP version restriction.

This is similar toroave/security-advisories and the reason onlydev-master exists there

Fixed in#33382, this is not needed anymore.