Problem/Motivation
We did this not long ago in #3113985: Update dependencies for Drupal 9 but there have been a few updates since, we should upgrade all our dependencies before beta 1.
Proposed resolution
Run composer update --with-dependencies and commit.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
The following PHP dependencies have been updated since 9.0.0-beta1:
- Symfony components have been updated from 4.4.4 to 4.4.5.
- Composer has been updated from 1.9.3 to 1.10.0, and
composer/installersis no longer pinned indrupal/core-recommended.comopser/installersmay now be upgraded whenever a new version is available and a Composer-managed site runscomposer update. - Several development dependencies including
behat/mink-browserkit-driver,composer/xdebug-handler,phpdocumentor/reflection-docblock,phpdocumentor/type-resolver, andphpspec/prophecyhave been updated to the latest compatible minor or patch versions.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | interdiff.3117342.12-16.txt | 3.55 KB | longwave |
| #16 | 3117342-16.patch | 42.89 KB | longwave |
| #12 | 3117342-12.patch | 43.05 KB | longwave |
| #10 | 3117342-10-do-not-commit.patch | 42.67 KB | longwave |
| #6 | 3117342-6.patch | 35.95 KB | alexpott |
Comments
Comment #2
longwaveComment #3
longwaveComment #5
longwaveDomCrawler related fails could be to do with https://github.com/symfony/symfony/pull/34059
Comment #6
alexpottThis fixes one of the tests locally.
Comment #8
alexpottI'm trying to convince Symfony to revert this change - see https://github.com/symfony/symfony/pull/34059 - sounds like a revert is going to happen.
Comment #9
alexpottSo the upstream revert occurred.
Comment #10
longwaveLet's try again with symfony/dom-crawler 4.4.x-dev and see what we need to fix while waiting for Symfony 4.4.6.
edit: oh, the revert was only done in the 3.4 branch so far, so this won't work anyway :(
Comment #12
longwaveWe can say that we explicitly don't want symfony/dom-crawler 4.4.5, but anything else is OK?
A deprecation message has also changed which is the cause of some other failures, fixed here.
Comment #13
berdirshould we keep both versions instead of changing it, so that it doesn't start to show up in case someone still has the old version? min-version testing and stuff like that.
Comment #14
alexpott#13 is tricky because essentially nothing is being tested. It seems harmless to keep in mind so why not - we can remove both when we've fix the root cause.
<3 This is a great idea.
Comment #15
catchFor #13 we could also raise the minimums above to ones with the old messages since we haven't released yet, there's an open issue discussing keeping out minimum versions inline with what's in composer.lock
Needs work for either option though I think.
Comment #16
longwaveAdded both deprecation messages, as that seems simplest for now; we don't need to bump the minimum version just for this.
Also changed the constraint slightly as you don't need both comma and space for AND, just space is needed.
Comment #17
alexpottThis looks great. RTBCing because this patch no longer contains my work.
Comment #19
catchCommitted 0d78f4c and pushed to 9.0.x. Thanks!
Comment #20
xjmComment #22
pameeela commentedNot sure how we summarise this in release notes - do we list all the changes, or link to a list somewhere else?
Comment #23
xjmThe summary in #3122112: Update dependencies for Drupal 8.9 has an example (not the raw command output, but the listed "highlights").
Comment #24
xjmWrote a release note (and rolled in #3134648: [backport, needs scheduling] Don't pin the composer/installers version in drupal/core-recommended since it is best mentioned in context of the Composer update).
Comment #25
xjmOops, this was already in beta2. I'll add this to the published release notes there.