Add a branch alias for 11.x

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).

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.

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?

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.

I still don't know how we can test this in the real world without actually committing it and testing on live Packagist.

+++ 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.

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?

@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.