Closed (fixed)
Project:
Drupal core
Version:
8.4.x-dev
Component:
base system
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 Aug 2017 at 14:47 UTC
Updated:
2 Oct 2017 at 19:15 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jibranComment #3
jibranUpdated some more dependencies.
Comment #6
jibranComment #7
jibranI think we should only update direct dependencies.
Comment #8
mile23It seems like our version requirements for those packages are fine as-is, unless there's a specific reason the lower versions are incompatible.
We really want to update the lock file, because generally we'd want newer versions available through
composer install.So for instance, like this:
Comment #9
mile23Comment #10
mpdonadioHere is just the change to the lockfile. #7 didn't apply anymore, this is really a rebase+minor merge and then reverting the changes to composer.json and core/composer.json; I didn't just edit out those hunks.
Do we want test-only patches with --prefer-lowest for these packages to double check our assumptions?
Comment #11
mile23--prefer-lowestwon't work until #2900800: Specify minimum phpspec/prophecy version in core/composer.json is in.Comment #14
mpdonadioOk, lets just redo this with
composer update composer/installers wikimedia/composer-merge-plugin guzzlehttp/guzzle mikey179/vfsstream phpunit/phpunit
to get the hash right.
- Updating composer/installers (v1.2.0 => v1.4.0)
- Updating wikimedia/composer-merge-plugin (v1.4.0 => v1.4.1)
- Updating guzzlehttp/guzzle (6.2.3 => 6.3.0)
- Updating mikey179/vfsstream (v1.6.4 => v1.6.5)
- Updating phpunit/phpunit (4.8.35 => 4.8.36)
Updated IS to reflect what composer picked for composer/installers
Comment #15
mile23In deference to #2843328: Enforce minimum PHP version in composer dependencies I applied the patch in #14 and then did
composer installThen I added config:platform:php:5.5.9 to composer.json and did
composer updateto check if we exceeded our platform minimum requirements.No difference in the packages found by Composer. Therefore: RTBC.
Comment #17
mpdonadioCurrent fail is b/c #2526150: Database cache bins allow unlimited growth: cache DB tables of gigabytes!. Once that gets reverted we can requeue.
Comment #18
mile23Looks like it was reverted: #2526150-276: Database cache bins allow unlimited growth: cache DB tables of gigabytes!
Retesting patch, setting back to RTBC.
Comment #19
xjmAh, so the minor-level library updates in here would have been allowed during the beta phase, but per https://www.drupal.org/core/d8-allowed-changes#rc they're triaged on a case-by-case basis during RC. (The patch-level updates are fine.) I'll get a second opinion from other committers.
Comment #20
mile23This isn't a change to the version requirements in composer.json. It's the lock file.
Also, we're working toward an automated version of the test you mention over here: #2874198: Create and run dependency regression tests for core
Comment #21
xjmOkay, yeah, good point. I checked with @larowlan and he is also +1. We can probably commit this before rolling RC2 on Wednesday.
How did this get out of sync? Are we forgetting to
composer updateor something when we update a dependency? Do we need to change our process for committing dependency updates?Comment #22
mile23I'm not sure we have such a process. :-)
Added some related issues towards that end.
All along, we've been told to use
composer update package/being-updatedwhich will only change the lock file to reflect that package.Comment #23
xjmThat could be the problem indeed. :P
I wonder if we can add a child page under https://www.drupal.org/docs/develop/using-composer on "Managing Drupal core dependencies with composer"? And possibly automation to https://github.com/alexpott/d8githooks/ to check for a changed
composer.jsonand complain if the lock file isn't updated appropriately.Comment #24
mile23In this issue, though, we have a bunch of packages that weren't ever updated in composer.json through patching. They just got stale in the lock file over time. composer/installers and wikimedia/composer-merge-plugin are clear examples of this.
It makes sense to have the lock file be a little stale during dev time because then everyone's using the same versions of stuff while they work. But at some point it should be updated before release. We could increase the safety of that with an automated test, such as https://github.com/paul-m/drupal_dependency_bounds_test or #2874198: Create and run dependency regression tests for core
Comment #28
catchCommitted patches to 8.5.x and 8.4.x respectively, thanks!
Comment #29
jibranCreated a quick follow-up #2909743: Again update non-Symfony dependencies in lock file before 8.4.0 for updating
zendframework/zend-diactoros masterminds/html5