Problem/Motivation

A spot check revealed that many of the php components that are subtree split and available on packagist depend on other components in their ^8.8 form even on the 9.x version.
This becomes a problem when a third party library depends on one of the drupal core components in any version (ie ^8.8 || ^9.0) which in turn depends on another drupal core component (like drupal/core-discovery or drupal/core-front-matter etc) on Drupal 9 those are then replaced with their Drupal 9 versions and thus it can not have 9 and 8 at the same time.

Steps to reproduce

https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/lib/Drupal/C...
https://packagist.org/packages/drupal/core-front-matter

Proposed resolution

Update the core components to require other core components with ^8.8 || ^9.0 if it is the case, or the more accurate dependency.

Remaining tasks

Identify all core components that can depend on either 8 or 9 versions.
patch
review
commit

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

drupal core php components on packagist work with both Drupal 8 and Druapl 9

CommentFileSizeAuthor
#12 3179197-12.patch3.44 KBbircher
#5 3179197-5-9.2.x.patch3.82 KBandypost
#5 3179197-5-9.1.x.patch3.82 KBandypost
#5 3179197-5-9.0.x.patch3.35 KBandypost
#5 3179197-5-8.9.x.patch3.36 KBandypost

Comments

bircher created an issue. See original summary.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue summary: View changes

Added steps

andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue tags: -undefined +Composer initiative
andypost’s picture

andypost
he/him
Primary language Russian
commented

If looks like it needs to be scripted per release

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Active » Needs review
StatusFileSize
new 3179197-5-8.9.x.patch3.36 KB
new 3179197-5-9.0.x.patch3.35 KB
new 3179197-5-9.1.x.patch3.82 KB
new 3179197-5-9.2.x.patch3.82 KB

Used this script

find core/lib/Drupal/Component -name composer.json -exec sed -i 's/\^8.8/\^9.2/g' {} \;

The last submitted patch, 5: 3179197-5-9.0.x.patch, failed testing. View results

andypost’s picture

andypost
he/him
Primary language Russian
commented

https://www.drupal.org/pift-ci-job/1864501 looks bot flux

naveenvalecha’s picture

naveenvalecha
He/Him
commented
Status: Needs review » Reviewed & tested by the community

Looks ready to me.

catch’s picture

catch
he/him
Primary language English
commented
Issue tags: +Needs followup, +Needs documentation updates

Patch is straightforward but we need to add this as a step to the branching process.

andypost’s picture

andypost
he/him
Primary language Russian
commented

@catch where to file follow up for branching?

xjm’s picture

xjm
she/her
Primary language English
commented
Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs release manager review

@andypost The branching script needs to be updated at https://github.com/xjm/drupal_core_release, and the manual steps documented at https://www.drupal.org/core/maintainers/create-minor-branch.

I'd like us to consider whether to add a script to core for this, or at least an API we can call, like we did for the Composer minimum-stability issue. Making changes to all these files with bash and sed will be ooglay and not very maintainable.

bircher’s picture

bircher
Location 🇨🇿
commented
StatusFileSize
new 3179197-12.patch3.44 KB

I am not sure requiring at least the same version is the best solution. So either we go the totally restrictive way and require the exact version and script it. Or we allow all versions that it is actually compatible with.
I know we don't currently don't test min-max. But I bet that the components fall under the API promise of drupal and since they inherit the same version as Drupal the difference between 8 and 9 doesn't mean the components API changed necessarily.
If we go the more permissive API route then when we just need to check things when we change the API of the individual components.
But I don't know how easy that would be to detect automatically.

andypost’s picture

andypost
he/him
Primary language Russian
commented

I think if it will be placed to release scripts, then on new branch creation it also needs update

I still not sure that 8||9 should be used

xjm’s picture

xjm
she/her
Primary language English
commented

So, theoretically speaking:

  1. A new minor is compatible with components from the previous minor (code that runs on 9.0 will also run on 9.1). However...
  2. The old minor is not necessarily compatible with components from the new minor, because the new minor adds new APIs. (Code that runs on 9.1 will not necessarily run on 9.0.)
  3. 8.9 and 9.0 have the same (undeprecated) API, but technically an 8.9-compatible (non-core) module could also call the deprecated code, so ?? what we should say there. I guess this is similar to 1 vs 2 above: Something that runs on 9.0 can also run on 8.9, but the reverse may not be true if deprecated code is used.
  4. 8.8 and 9.0 are mostly compatible, say 98% but not 100%, because there was some limited stuff we could only do in 8.9.
xjm’s picture

xjm
she/her
Primary language English
commented
Status: Needs review » Needs work

We recently made a similar change to the project templates: #3182959: Prevent pre-release milestones from downgrading to earlier releases.

The branching script was updated accordingly: https://github.com/xjm/drupal_core_release/commit/109e84fe6bf6c98cf334e3...

So, I think we should probably just use the current minor branch as in those template changes. Using a 9.0.x version of a component with Drupal 9.1.x could have unexpected and strange results.

It's too late to change this in 9.0.x (which is security-only now), but we could fix it in 9.2.x and discuss whether it's safe to fix in 9.1.x as well.

xjm’s picture

xjm
she/her
Primary language English
commented
Version: 9.0.x-dev » 9.2.x-dev

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented
Status: Needs work » Closed (duplicate)
Issue tags: -Needs followup
Related issues: +#3272110: Drupal 9 and 10's Drupal\Component composer.json files are totally out of date

#3272110: Drupal 9 and 10's Drupal\Component composer.json files are totally out of date is in, so now all components are made to require their current release version friends. For instance, release 9.5.x-dev will force all components' requirements to have constraints such as "drupal/core-utility": "9.5.x-dev".