+1 for being clearer about what should work and not to be able to be stricter in the future

@HeahDude Yeah, I am already preparing some PRs to improve DX around this.

@HeahDude see#28724

@xabbuh Do you already know if this will be accepted? Because if it is not we have to fix our JS, otherwise we would only have to add this version as conflict, and we could release a new working version immediately.

@danrot Adding the conflict rule will be enough.

I've added the conflict for symfony 3.4.16 and 3.4.17 in ourcomposer.json, but if you don't set our latest version (1.6.22) as minimum in the project composer.json, composer will install Sulu 1.6.21, so that it can use Symfony 3.4.17, which then still breaks the installation (hope you understand what I mean, otherwise I can elaborate further 🙈).

So people are really struggling with the installation of our product... Is there any other thing we can do, apart from kindly asking you to get this merged and release it? 😊

I've added the conflict for symfony 3.4.16 and 3.4.17 in ourcomposer.json, but if you don't set our latest version (1.6.22) as minimum in the project composer.json, composer will install Sulu 1.6.21, so that it can use Symfony 3.4.17, which then still breaks the installation (hope you understand what I mean, otherwise I can elaborate further 🙈).

Huh? I have "sulu/sulu": "~1.6.0", as a dependency in several projects (all of our Sulu projects, actually) andcomposer update correctly installs Sulu 1.6.22. The only time this would fail is if people did the update last week when Sulu 1.6.22 wasn't out yet but Symfony 3.4.17 was already - like we did. But even then an Update after the release of Sulu 1.6.22 fixed it. Why would you think people are locked to Sulu 1.6.21?

Just tested it again, had a project with"sulu/sulu": "~1.6.22", where 1.6.22 was installed, no surpirse so far. Then I changed mycomposer.json in the following way (I assume that's what most Sulu users have in theircomposer.json):

-        "sulu/sulu": "~1.6.22",+        "sulu/sulu": "~1.6.0",

Then I executed anothercomposer update, and that's the output:

daniel@macbook ~/D/s/sulu-standard $ composer updateLoading composer repositories with package information                                                                                                                                                             Updating dependencies (including require-dev)                                                                                                                                                                      Package operations: 0 installs, 3 updates, 0 removals                                                                                                                                                                - Updating symfony/symfony (v3.4.15 => v3.4.17): Loading from cache                                                                                                                                                - Downgrading sulu/sulu (1.6.22 => 1.6.21):  Checking out c0c04cd95e                                                                                                                                               - Updating dantleech/phpcr-migrations-bundle (1.0.0 => 1.1.0): Loading from cache

In addition to that composer even tells me that Symfony is the reason for not installing 1.6.22:

daniel@macbook ~/D/s/sulu-standard $ composer why-not sulu/sulu 1.6.22sulu/sulu  1.6.22  conflicts  symfony/symfony (2.8.10 || 3.4.12 || 3.4.16 || 3.4.17)

Just realized that it works, if the"sulu/sulu" require is before the"symfony/symfony" require 😕 Feels a bit weird, but we can't fix that for existing projects 😞

Just realized that it works, if the"sulu/sulu" require is before the"symfony/symfony" require 😕 Feels a bit weird, but we can't fix that for existing projects 😞

Ah! See, we have "config": { "sort-packages": true }, in all our projects, which puts Sulu before Symfony. 🙂

And sincesort-packages will be the default with symfony flex, that doesn't make me feel more comfortable 🙈 That means that if we have a conflict with a package that is ordered after sulu alphabetically there is no way to fix this 😕

Anyhow, please somebody merge this to the LTS branches 2.8 and 3.4 so we can safely rely on backwards compatibility again. 🙂

Thank you@xabbuh.