Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Symfony 2.8.4 has been released. Since we are now targeting Symfony version ~2.8 in our composer.json file this means that any project that uses a composer based workflow receives 2.8.4 as soon as they update their dependencies.
Proposed resolution
Update to Symfony 2.8.4 and fix any issues that arise.
Remaining tasks
User interface changes
None expected.
API changes
Some changes to interface signatures expected in Symfony components. It still needs to be determined if this affects Drupal code.
None.
Data model changes
None expected.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2702677-12.patch | 21.16 KB | chrko |
| #3 | 2702677-3.patch | 21.25 KB | pfrenssen |
Comments
Comment #2
pfrenssenComment #3
pfrenssenKicking this off by launching a test with updated dependencies. I also updated the version strings to track point releases
~2.8.4. It was originally configured to follow minor releases~2.8. This seems better to me from the perspective of someone who uses composer to manage their projects. We are already seeing minor bugs pop up when updating Symfony point releases, let alone in minor releases. Discussion welcome.Expecting some failures similar to this, we encountered this when running Behat tests against updated Symfony components (ref https://github.com/jhedstrom/drupalextension/pull/266).
Comment #4
pfrenssenComment #6
pfrenssenPromising, there was only one failure and it looks like a random test failure.
Comment #7
pfrenssenComment #8
pfrenssenComment #9
pfrenssenIt seems that the interface compatibility notices we were getting in the tests for Behat Drupal Extension are due to version conflicts between Symfony components with different point releases. As long as all packages are in sync this does not appear to be a problem.
Since we are updating all Symfony components at once this interface mismatch does not affect Drupal core. Affected projects can easily fix it by checking the versions in their composer.lock file. Lowering priority to normal.
Comment #10
jibranRelated #2703319: Update to symfony/css-selector 2.8.
Comment #11
jibranEverything is passing here so RTBC.
Comment #12
chrko CreditAttribution: chrko commentedComment #13
chrko CreditAttribution: chrko commentedI don't think that the version constraint should be updated from "~2.8" to "~2.8.4" because the tilde operator includes the version 2.8.4 and following version, so I ran only composer update on the symfony packages. Are there any bug fixes in symfony 2.8.4 we are depending on?
Additionally according to the original patch I updated the version constraint of the css-selector component referencing also the issue #2703319: Update to symfony/css-selector 2.8 of @jibran.
Comment #14
pfrenssen@chrko, can you please give some more reasoning why you think it should be "~2.8"? If you use "~2.8" then you basically are declaring that the current version of Drupal 8 is compatible with Symfony 2.8, 2.9, 2.10 and so on.
As I explained in my comment #3 whatever we put in our composer.json file does not only affect Drupal core itself, but also projects that are built with composer. If you use the version "~2.8" then Symfony will update to 2.9 as soon as it is released for Composer based projects.
I think we can expect this to cause projects to break, in fact we have already seen breakage when updating to new minor Symfony releases in the past. See for example #2611816: Update to symfony 2.8 and #2278353: Update to Symfony 2.5.
Comment #15
chrko CreditAttribution: chrko commentedOkay, unfortunately symfony minor versions are integrating some features and bug fixes which aren't backward compatible.
But back to the version constraint and composer: The composer.json included in drupal core should fit the core requirements. If a third party project needs a more limiting version constraint they should include these in their composer version constraints.
Following the semantic versioning scheme we should depend on "~2.8" because minor versions updates shouldn't break existing code. Also in this specific case symfony2.8 will be the last minor release of the symfony2 branch according to the project homepage.
We should monitor the behaviour of symfony upgrades again starting at 3.* because the readjustment of the release and development cycle of their components. I think they also noticed that they are sometimes breaking some parts of the semantic versioning.
So my proposal is the following: Staying at "~2.8" and evaluate the behaviour during minor release upgrades of the symfony3 branch.
Comment #16
dawehnerTo be clear, ~2.8.2 will allow to add 2.9 as well, if there is any dependency in some other package.json file
Comment #17
jibran#12 also works.
Comment #18
catchCommitted f1d08c2 and pushed to 8.2.x. Thanks!
Leaving RTBC for 8.1.x and tagging rc target. I'd like to get this in if we can during the rc, although theoretically the patch release update could also happen in a patch release.
Comment #20
pfrenssenThanks! I just checked the patch against 8.1.x and it applies cleanly.
Comment #21
alexpott+1 to this issue being an rc target. Shipping releases with the latest versions of dependencies seems like a good idea to me.
Comment #23
catchCherry-picked to 8.1.x, thanks!
Comment #24
xjm