conflict rules for v3 should also forbid a v2 package

[stof]

As the goal is to ensure that all packages are using the v3, we need the conflict with <3 too, not only >= 4 (this was OK for version 2 as Symfony 1 does not exist for these component.

[nicolas-grekas]

I'm not sure why. People always get the highest package available so that if they install v3 here, but some other dep requires v2.8 of some package, it's not our duty to forbid it I'd say (but people to check why.)
WDYT?

[nicolas-grekas]

But if you mean this is required because of #4 that we missed in v2, maybe we can push-force a new tag?

[stof]

@nicolas-grekas if I require symfony/lts v3, I don't want another dependency to make one of the components use 2.x. I want to be sure that all components I'm using are on v3 (and get a dependency conflict if one of my dependencies does not support Symfony 3). Otherwise, I would not be using the Symfony 3 LTS release.

I'm even wondering whether the conflict rule should not be < 3.4 here, because only 3.4.x is LTS for Symfony 3. The 3.3 components are not LTS.

[nicolas-grekas]

The goal is to be able to start with 4.0 in a LTS-rolling mode: you update your project every 6 months and you effectively get very-LTS (VLTS).
And I don't think we should force the lowest bound: that will only be annoying people that want the upper bound but are caught by the lower one for a reason they were OK to accept (and for people really wanting 3.x ONLY, they should watch their deps better.)

[nicolas-grekas]

Closing as discussed (and because it's staling :) )

[Nyholm]

Look at this PR: php-http/client-common#90

I would like travs to fail when Im using lts v4. Right now it is installing symfony/options-resolver:v3 and the test pass. That is not what I expected when requiring lts v4.

(I know what I did wrong and how to fix it. Im just want to point out that this behaviour was not expected. )

[nicolas-grekas]

I think this may mean we need another package for enforcing the lower bound.
Having both boundaries be enforced in the same package is too authoritative in my opinion: you cannot escape the rules, which means if you're to have a mix of v4+3 components because that's actually mandatory for some other dep to work, then you should be allowed to technically.

But I also understand the need for the CI part. So maybe another package that enforces lower bounds only or some similar idea that could allow the flexibility I just described?