Add a branch alias for 11.x

Not entirely sure how this is supposed to work even after reading the documentation, so let's suck it and see.

The last submitted patch, 2: 3364646.patch, failed testing. View results →

lock file missed update

Don’t know if this should happen here or a separate issue, but I think Drupal::VERSION on 11.x branch (for now) should also be 10.2.0-dev

I confess to not fully understanding if all this diff is legit, but here's what I got after applying patch #2, changing Drupal::VERSION, and running composer update nothing. Let's see if this helps. 😅 Also uploading a partial patch with just the changes to Drupal::VERSION and composer.(json|lock).

#6 looks pretty good. We may need to update https://github.com/xjm/drupal_core_release/blob/main/branch.sh to deal with this, but should check it's what we want first.

The last submitted patch, 6: 3364646-6.full_.patch, failed testing. View results →

Maybe instead of that branch should be 10.2.x with alias 11.x-dev?

+++ b/core/lib/Drupal.php
@@ -75,7 +75,7 @@ class Drupal {
-  const VERSION = '11.0-dev';
+  const VERSION = '10.2.0-dev';

If this change applied then COMPOSER_ROOT_VERSION=11.x-dev composer update --lock is the only working command to create patch 6-full

Using 10.2.x-dev fails

core$ COMPOSER_ROOT_VERSION=10.2.x-dev composer update --lock
> Drupal\Composer\Composer::ensureComposerVersion
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/core == 11.9999999.9999999.9999999-dev, it is satisfiable by drupal/core[11.x-dev] from composer repo (https://repo.packagist.org) but drupal/core[10.2.x-dev] from path repo (core) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 2
    - Root composer.json requires drupal/core-project-message == 11.9999999.9999999.9999999-dev, it is satisfiable by drupal/core-project-message[11.x-dev] from composer repo (https://repo.packagist.org) but drupal/core-project-message[10.2.x-dev] from path repo (composer/Plugin/ProjectMessage) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 3
    - Root composer.json requires drupal/core-vendor-hardening == 11.9999999.9999999.9999999-dev, it is satisfiable by drupal/core-vendor-hardening[11.x-dev] from composer repo (https://repo.packagist.org) but drupal/core-vendor-hardening[10.2.x-dev] from path repo (composer/Plugin/VendorHardening) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.

Looking at the failures in #6 I wonder if they are chicken and egg failures - composer is saying it can't find 10.2.x branch, but is that because we don't have the branch alias exposed to packagist because this issue isn't committed yet?

If so, then it might actually be RTBC? Or we might have to skip those two tests here, commit it, then open an issue to unskip just in case?

I am not entirely sure. The issue here appears to relate to these in the top level composer.json:

    "require": {
        "drupal/core": "self.version",
        "drupal/core-project-message": "self.version",
        "drupal/core-vendor-hardening": "self.version"
    },

The error seems to be saying that:

• self.version is resolving to 11.x-dev
• the path repos (local disk) provide 10.2.x
• packagist can provide 11.x

but the path repos have higher priority than packagist and so it is refusing to install. IIRC we use the path repos in preference because the tests shouldn't rely on network access to packagist at all. Do we need the path repos to provide both versions somehow?

OK this rings a bell, so no chicken egg but more of a real problem.

https://github.com/composer/composer/issues/7847 looks related.

Can we just use * instead of self.version in the hunk above?

The metapackage templates need to specify the new alias in their dependencies instead of the original branch name, that makes the metapackage related tests pass.

ComponentsIsolatedBuildTest appears to be broken and we are running into that here. I don't understand why it only hardcodes the Render and Utility components; we need all the dependee components to be registered as path repos to avoid hitting Packagist. The fix registers all components as path repos.

The change to core/lib/Drupal/Component/FileSecurity/composer.json is unnecessary, this was part of an earlier failed attempt.

Just #14 with the hunk mentioned in #15 removed.

+++ b/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php
@@ -66,12 +66,10 @@ public function testComponentComposerJson(string $component_path): void {
+      $package_name = 'drupal/core' . strtolower(preg_replace('/[A-Z]/', '-$0', substr($path, 1)));

This is a bit hacky and maybe we should load the package name from the actual composer.json?

Could we schedule a time next week, commit it, and do some immediate testing.

If anything is broken we revert?

Nifty.

Can we file a followup against https://github.com/xjm/drupal_core_release pretty please? Thankses.

Opened the follow-up https://github.com/xjm/drupal_core_release/issues/17

Committed b28e3b7 and pushed to 11.x. Thanks!

Let's find out what happens :)

I'm using https://github.com/joachim-n/drupal-core-development-project and was attempting to run a fresh installation of it today. Installation is broken: https://github.com/joachim-n/drupal-core-development-project. I'm wondering if it might be related to this update?

Automatically closed - issue fixed for 2 weeks with no activity.

@pyrello It's not related to this fix, but it's caused by the 11.x branch being secretly 10.2.x.

I've just updated the README to explain how to deal with it.