Updating from drupal 8.4.4 to 8.4.5 do nothing due webflo/drupal-core-require-dev

[calbasi]

Hi, just trying to update with:

composer update drupal/core --with-dependencies

But composer don't update anything ;-)
Then:

composer why-not "drupal/core:8.4.5"

Get:

webflo/drupal-core-require-dev 8.4.4 requires drupal/core (8.4.4)

So I should do:

composer update drupal/core webflo/drupal-core-require-dev --with-dependencies

to update drupal core...
But I wonder if this is a "by design" behavior... I don't think so...

[webflo]

True, the DX is not optimal because of this change. We should write some new documentation.

//cc @alexpott

[alexpott]

Well the good thing is that at least they are being kept in sync. I assume that the webflo/drupal-core-require-dev requirement in composer.json was 8.4.4. Would a more relaxed requirement allow it to be updated when you update just core?

[lvbeck]

same thing happens when I try to update drupal 8.4.5 to 8.5.0, composer won't update anything.

even I run composer update drupal/core webflo/drupal-core-require-dev --with-dependencies, still no update is installed.

please provide more information about how to update drupal core from 8.4 to 8.5, thanks!

[webflo]

@lvbeck https://orkjern.com/updating-to-drupal-85-with-composer should help

[lvbeck]

@webflo thank you, it works after I manually edit the composer.json

"drupal/core": "~8.5"
"webflo/drupal-core-require-dev": "~8.5"

and run
composer update drupal/core symfony/config webflo/drupal-core-require-dev --with-dependencies

[webflo]

@lvbeck We improved the update instructions in #366

This should help in the most cases. I keep the issue open for a couple of days, for users with trouble updating to 8.5.

[rodrigoaguilera]

Maybe this really long command can be added to the "scripts" section? update-core maybe as a name?

I think is really great the introduction of webflo/drupal-core-require-dev but I wish it had as minimal trade-offs as possible.

[alexpott]

@rodrigoaguilera out of interest is there a reason you are not doing just "composer update". Most of the problems come from trying to update just one thing where actually your project has a web of dependencies.

I vote for not putting a command in scripts because you can't guarantee it is going to work. The next time it'll be something other than symfony/config

[rodrigoaguilera]

Is just that we do not pin other dependencies in the root composer file and composer update will bring updates from all of them. I feel is a good practice to update a whole project piece by piece and easier to pinpoint commits that introduced regressions.

I am composer-savvy and I have no problem researching on why a package is not updating but I'm worried about other developers.

The great thing is that this is just a template and I can add the script on my copy since I really trust symfony not break compatibility. I guess when the case is different than symfony/config someone with composer experience needs to help.

[calbasi]

@alexpott For the case of little projects, already in production, without DEV/STAGING even git repo I think a general update (composer update) is not the best, because as commented by @rodrigoaguilera , your main goal is just apply security updates without regressions risk.

There are lots of websites / projects like this... And drupal 8, composer, etc. maybe are not doing easy for them (forget shared hosting, updates just downloading .tar.gz packages from drupal.org, etc.).
I think, but that's just my opinion, we should care about them, not loosing critical, important or maybe desirable features (use of composer / profit symphony ecosystem could be two of them), and find easy alternatives for common tasks.

For example, I've read about issues upgrading from 8.3 to 8.4 (and now to 8.5)... core/drush issues related to dependencies of symphony for drush 9, problems with drush < 8.115 , etc. etc. Really exhausted about lots of problems appear when just trying to apply a security update. Can little customers pay for it? Should they think in wordpress, etc?

[alexpott]

@calbasi well in an ideal world "composer update" would just work when it comes to updating your project and things would not break. Trying to do partial updates is tricky and there is no one composer command that we can communicate that will just update drupal/core on a project given that people are free to include whatever dependencies they like and these dependencies can cause issues. The reason symfony needs to be included to go from 8.4.x to 8.5.0 is because of something in drupal console. Next time it will be something different.

Also being on the latest version of everything in your project is safer because if there is a security release for one of your dependencies and your project is up-to-date then it will be easier updating. Ie. the thing that needs updating might require everything else to be updated and if you've not done that then you've got problems. By telling people to partial updates we're just storing up problems for a later date.

That said, I do understand that the Drupal 8.x minor update path has been really really painful because of the Symfony update to version 3 and issues with Drush. Now we've got to Symfony LTS release (3.4.x) this should not happen again in the Drupal 8 cycle. And also now that the recommended approach is to install Drush per project via composer we shouldn't have the complexities there either. Also we are considering doing security support for more than just the current minor - see https://www.drupal.org/project/drupal/issues/2945200.

[calbasi]

Thanks for your comments, @alexpott I appreciate them!
In fact, I didn't realize that just thinking in drupal modules security updates, I can miss all other non drupal security updates... Composer update can try to solve them, just updating all php stuff... Regressions could be a risk, as I told you, but security holes are a risk too :-)
I'd like to know what happens where a non-drupal dependency has a security update or just a security issue. Is there a procedure to tag related drupal modules as "insecure"?

[vistar]

https://orkjern.com/updating-to-drupal-85-with-composer not help.

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/core 8.6.x-dev requires php ^5.5.9|>=7.0.8 -> your PHP version (7.1.9) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - drupal/core 8.5.x-dev requires php ^5.5.9|>=7.0.8 -> your PHP version (7.1.9) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - drupal/core 8.5.0-rc1 requires php ^5.5.9|>=7.0.8 -> your PHP version (7.1.9) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - drupal/core 8.5.0-beta1 requires php ^5.5.9|>=7.0.8 -> your PHP version (7.1.9) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - drupal/core 8.5.0-alpha1 requires php ^5.5.9|>=7.0.8 -> your PHP version (7.1.9) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - drupal/core 8.5.0 requires php ^5.5.9|>=7.0.8 -> your PHP version (7.1.9) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - Installation request for drupal/core ^8.5 -> satisfiable by drupal/core[8.5.0, 8.5.0-alpha1, 8.5.0-beta1, 8.5.0-rc1, 8.5.x-dev, 8.6.x-dev].

[alexpott]

@vistar the clue is in the error message - you need to change whatever you have set to config.platform.php to. It looks like someone has set it at PHP 7.0 but Drupal is not compatible with 7.0.0 it is compatible with 7.0.8 and up.

[webflo]

I don't have a better solution for this atm, but the docs under https://github.com/drupal-composer/drupal-project#updating-drupal-core have a very similar command.

[ProCycleDev]

Whoops sorry I posted my comment in the wrong project. Should have gone here webflo/drupal-core-require-dev#3 (comment)

[Jelle-S]

@calbasi well in an ideal world "composer update" would just work when it comes to updating your project and things would not break. Trying to do partial updates is tricky and there is no one composer command that we can communicate that will just update drupal/core on a project given that people are free to include whatever dependencies they like and these dependencies can cause issues. The reason symfony needs to be included to go from 8.4.x to 8.5.0 is because of something in drupal console. Next time it will be something different.

Also being on the latest version of everything in your project is safer because if there is a security release for one of your dependencies and your project is up-to-date then it will be easier updating. Ie. the thing that needs updating might require everything else to be updated and if you've not done that then you've got problems. By telling people to partial updates we're just storing up problems for a later date.

That said, I do understand that the Drupal 8.x minor update path has been really really painful because of the Symfony update to version 3 and issues with Drush. Now we've got to Symfony LTS release (3.4.x) this should not happen again in the Drupal 8 cycle. And also now that the recommended approach is to install Drush per project via composer we shouldn't have the complexities there either. Also we are considering doing security support for more than just the current minor - see https://www.drupal.org/project/drupal/issues/2945200.

Yes, in an ideal world it would. Unfortunately, the world is not always ideal. For security updates we usually execute composer update drupal/core --with-all-dependencies, which works everytime, except of course when webflo/drupal-core-require-dev is required in composer.json. I'm not really sure why the requirement was added. Is this documented somewhere?

[leymannx]

@Jelle-S, maybe start reading #506 and follow any linked issue.

Otherwise outdated. Everybody still having a problem please try to git diff your composer.json to the latest composer.json in the repo and refactor accordingly. Many thanks 🙂