Match the version of drupal/core-* metapackages

> The reason that we don't want to require drupal/core with self.version is that it makes upgrading harder.

In what way?

We now recommend that upgrading core be done with "composer update drupal/core*" which updates both packages simultaneously. Won't the dependency work ok with that?

> The reason that we don't want to require drupal/core with self.version is that it makes upgrading harder.

In what way?

I was thinking about why Greg said this and what I saw in https://www.drupal.org/files/issues/2020-08-03/3163114-6.patch → ... so do we really expect and reality also confirms that within the same Drupal minor versions, these meta packages could be on different versions at any time and everything should work? Because if not, the current solution with self.version in the MR is the only way to move forward, if not, then we get back to patch 6 and only lock on major.minor.

It occured to me that Greg's comment is 4 years old and maybe it is from those days when core-recommded did not allow patch version update of dependencies. In those days the concerns he raised regarding self.version was valid.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Still mergable according to Gitlab.

In what way?

We now recommend that upgrading core be done with "composer update drupal/core*"

I believe I answered this question elsewhere recently, but I am not sure where, so I will re-post here for context.

During the development of Drupal 8.8.x, composer update drupal/core* failed to update, because Composer became confused by the chained strong constraints. One might think that strong constraints would make the dependency graph easier to resolve, because it branches to fewer variations, but for whatever reason, it was harder for Composer in the past. If modern Composer deals with it well, then this change is an improvement.

If I recall correctly, the conflict statement that I recommended worked better (e.g. #9 can be rewritten to allow only one patch version). I don't recall if there was any reason we didn't add it; maybe just never got to it. We certainly did not want to encourage folks to mix different core versions.

This was the Slack thread: https://drupal.slack.com/archives/C392CHBEW/p1720016380610809

I also dumped it via Slackdump before it gets lost, see attachment.

Thanks for looping back to this thread, I'll also do that early next week.

Thanks for saving the conversation before it was lost @mxr576!

As we talked about in #2952616-17: Adopt CommonMark spec for Markdown files → , an automated Slack dumper service would be awesome, pulling down and saving all the great Drupal conversations. A daily drupal.org/project/drupal issue could work as a data repository, consolidating the text for inclusion when searching in Drupal core issues :-)

Drupal Slack Dump for 2024-07-03

Besides a CR any next steps needed here?

Well, Greg expressed his opinion in the referenced Drupal Slack about why he would not rely on core-dev for running tests on downstream projects, but he did not mention that in #27.

I think we are on the an agreement regarding:

We certainly did not want to encourage folks to mix different core versions.

I do not think that enforcing this with conflict or require would make a difference in Composer 2.7+... if there are strong concerns we can try figure that out somehow... without that we can merge the current approach and switch to other when it proved to be problematic.