[Policy] Branch Naming: Use an 11.x branch for HEAD, then use 'main' when d.o can support it

Created on 7 July 2022, almost 2 years ago
Updated 8 September 2023, 10 months ago

Problem/Motivation

Background: We currently do most of our development against the "Most recently opened Development Branch", and when the first alpha of that minor is released, we open a new branch, which then logically changes what the "Most recently opened Development branch". Anything that's eligible to apply to either the currently supported minor or previous minor (security patches) is then cherry picked to those lower branches.

Problem: This means that our "logical HEAD" of core is a moving target that changes every six months, and perhaps more frequently when we add in Major version branch openings as well.

This causes a couple of problems:

  1. Issues are assigned to a specific branch, like "9.3.x" that then have to be re-assigned to the new logical HEAD. In the vast majority of cases these issues aren't actually targeting the specific branch, they are trying to chase the logical HEAD, and when that HEAD changes labels (i.e. from 9.3.x->9.4.x) we have to go through a process to manipulate all of the issue metadata to move them.
  2. Now that we have merge requests, those MRs also need to be migrated to be filed against the latest logical HEAD. We currently do not have a programmatic way to accomplish this, and the permissions on gitlab only allow the opener of the MR to do it, so even manual community issue grooming is onerous, and sometimes demands a new MR be opened to move branches.
  3. A new user to the project doesn't have an obvious signpost where development happens. They have to look at all the open branches, and deduce that the highest numbered one is where all the momentum is happening. -> it is more common in projects for main is the place where work happens.

Proposed resolution

Ideally we would switch our logical HEAD to main asap, however Drupal.org does not have support for non-numeric branches out of the box.

Instead, we can implement an interim step on Drupal.org which should work with minimum or zero d.o changes and only minor core changes:

  • Branch 11.x instead of 10.2.x now (i.e. 10.1.0-alpha/beta period).
  • 11.x will follow 10.x minor release commit rules for the time being, no 11.x-specific patches yet and no 10.2.x branch.
  • When we are ready to tag 10.2.0-alpha1, we would then branch 10.2.x and tag all 10.2 releases from there. The 11.x branch then continues as HEAD.
  • When we need to diverge 11.x and 10.x, we would branch 10.LAST.x. 11.x would then start to get 11.x-specific commits
  • When we're ready to tag 11.0.0-alpha1 we would branch 11.0.x and tag all releases from that branch.
  • Continue with 11.x minor branches branched off 11.x when they reach alpha
  • Hopefully, by the time we're working on 12.x, we'll be able to branch 'main' and work from that indefinitely.

Advantages:
One bulk issue update from 10.1.x to 11.x, and eventually a bulk issue update to 'main' in two or so years, instead of every six months. Same with branch retargeting.

DIsadvantages:
It is weird and non-semantic to use 11.x as the target for 10.x commits and release branches, however this will only be the case for a few months, then it will fold into sync with the 11.x release cycle anyway.

Original Proposal: Change our logical HEAD to main. All of our current existing policies would still apply, with one exception: instead of opening "the next branch for development" when we release an alpha, we instead open the release branch for that release at the time the alpha is released. (Do nothing with d7 and leave it as it is)

Example

(Now out of date in terms of current version, but still conveys the idea)

The current regime:
All of our commits happen to 9.3.x and:

The proposed strategy:
(rename current 9.3.x to main)
All of our commits happen against the main branch

So essentially: we develop in main untilwe open a release branch, at the same time that we make that branch's first release.

Question: The one part of this change that I'm unfamiliar with is what we do around major version branch releases:

If we are opening 9.4.x and 10.0.x at different times, then with this change in place we would open the 9.4.x branch when we are ready to start committing '10.0.x only' changes to main

Implementation considerations:

  • Add main as a 'dev' release?
  • Do we need both a 'main' and a 'next'?
  • Allow main to exist in the version selector for issues
  • Look at places where 'branch' might be standing in for a version.
  • disable force pushes to main - at least for core.

Remaining tasks

  • Documentation changes, including wiki pages and policy

User interface changes

Release notes snippet

๐ŸŒฑ Plan
Status

Fixed

Version

11.0 ๐Ÿ”ฅ

Component
Otherย  โ†’

Last updated about 7 hours ago

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States hestenet Portland, OR ๐Ÿ‡บ๐Ÿ‡ธ

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    +1 to this change.

    However, are we waiting until after we migrate all issues off d.o and into Gitlab? I know the d.o dev team isn't excited about making any changes to DrupalCI or project_issue these days. That said, I'm not sure how many d.o changes would even be needed. Perhaps something in project_release to let us have a 'main' version number from a 'main' branch (instead of the currently enforced mapping of well-named branches to specific versions).

    Frankly, if we're keeping projects and release on d.o, and only moving issues, we'll need to do the above change, regardless. So I'm not sure that's a reason to delay this for the Gitlab issue migration.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

    Since changing the target branch of a merge request has proven to be cumbersome at best, I think we do need to make this change soon. It is extra work checking over Drupal.org issues integration, but worth it to make moving to merge requests and GitLab CI more doable.

    (We could start using a 10.x branch right away, and reduce the frequency of default branch changes, but that would still require switches when we go to 11.x and/or main)

    The main concern is timing - a good spot in the core development cycle, and fitting this in among the big projects the Drupal Association Engineering team is working on. We have been keeping track of potentially-good windows.

    The work involved is somewhat like the move to semantic versioning - finding all the places where the version number format is relevant, seeing how they handle a main branch, fixing issues found. main should be installable with Composer, so working backward from that should hit most of the relevant code.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    p.s. There's precedent from the dark ages: We used to have a "HEAD" version for d.o issues. I believe that just required some super-user hacks, but otherwise, It All Just Worked(tm). Perhaps this really won't be that hard from a project* standpoint, at least if we're only letting core do this.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    Oh hah! I was just looking at the ridiculous list of projects I maintain, and noticed https://www.drupal.org/project/issues/feature โ†’ -- behold:

    https://www.drupal.org/project/issues/feature?version=master โ†’ [sic]
    https://www.drupal.org/project/feature/releases/master โ†’

    So yeah, as I thought, project_release and project_issue mostly support all this already. ๐Ÿ˜‚ I bet all we need is a small patch to version_control_release or whatever it is that maps Git branch names to d.o release versions...

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

    main should be installable with Composer

    I think thatโ€™s where a good amount of the work is. This isnโ€™t just dusting off vestigial functionality.

  • ๐Ÿ‡ญ๐Ÿ‡บHungary Pasqualle ๐Ÿ‡ญ๐Ÿ‡บ Budapest

    I see one issue with this change. Bug reports filed against the "main" version are not really helpful. If the reporter does not specify a version, then it needs extra work to figure out which versions might be affected by the bug.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    (We could start using a 10.x branch right away, and reduce the frequency of default branch changes, but that would still require switches when we go to 11.x and/or main)

    That might be a good interim step - making MR target branches less frequent is the most urgent part of this (and should block a gitlab migration in my opinion, people still end up reverting to patches or opening multiple MRs on the same issue due to that).

    The main concern is timing - a good spot in the core development cycle,

    If we have a 10.x branch, this would allow us to open (for example) 10.2.x only a bit before we want to tag an alpha I think, so potentially a good timeline would be:

    1. Open 10.x very soon.
    2. Open 'main' immediately after 10.1.1 is tagged

    Then the worst case might be 10.1.2 having to wait a month or similar but it wouldn't be in the middle of trying to tag rcs every week or so.

    The only issue I can think of with a 10.x branch is that once we've got the main branch up and running properly, there's no use for the extra 10.x branch. But... if we can open 'main' before we need an 11.x branch, that might be enough - just retire it some time around then. Or it might even start being useful again at that point, since it'd provide a static target for 10.x backports from 11.x.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    Variation on #15:

    Open 11.x very soon, and treat that as 'main', until we can have a real 'main' branch, we would be able to run like that until we need to branch 12.x which should hopefully be enough time to get a 'main' branch proper.

    That way, we can target all MRs (except explicit backports) and issues at 11.x and stop doing bulk updates etc.

    Then there's a question of when we start putting 11.x-only commits into 11.x, but that seems like a minor issue to sort out compared to bulk updates every six months or rushing the DA.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    @catch and I discussed the above proposal and I agree it would be a worthwhile first step that would allow us to adopt the new process and get a lot of the advantages using the infra currently available. Then, we can switch to main from 11.x in a few years when the DA has capacity for less critical changes like d.o support for it.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    I tested branching 11.x locally today. The diff seems fine at first glance:

    commit 516503cd7887424248bc6dcdf7068d19979bba65
    Author: xjm <xjm@65776.no-reply.drupal.org>
    Date:   Tue Apr 18 13:45:30 2023 -0500
    
        Drupal 11.x-dev
    
    diff --git a/composer.lock b/composer.lock
    index e88cc94053..18ea03064a 100644
    --- a/composer.lock
    +++ b/composer.lock
    @@ -487,7 +487,7 @@
             },
             {
                 "name": "drupal/core",
    -            "version": "10.1.x-dev",
    +            "version": "11.x-dev",
                 "dist": {
                     "type": "path",
                     "url": "core",
    @@ -644,7 +644,7 @@
             },
             {
                 "name": "drupal/core-project-message",
    -            "version": "10.1.x-dev",
    +            "version": "11.x-dev",
                 "dist": {
                     "type": "path",
                     "url": "composer/Plugin/ProjectMessage",
    @@ -677,7 +677,7 @@
             },
             {
                 "name": "drupal/core-vendor-hardening",
    -            "version": "10.1.x-dev",
    +            "version": "11.x-dev",
                 "dist": {
                     "type": "path",
                     "url": "composer/Plugin/VendorHardening",
    diff --git a/composer/Metapackage/CoreRecommended/composer.json b/composer/Metapackage/CoreRecommended/composer.json
    index 5bdeadfefd..4f6ac08590 100644
    --- a/composer/Metapackage/CoreRecommended/composer.json
    +++ b/composer/Metapackage/CoreRecommended/composer.json
    @@ -7,7 +7,7 @@
             "webflo/drupal-core-strict": "*"
         },
         "require": {
    -        "drupal/core": "10.1.x-dev",
    +        "drupal/core": "11.x-dev",
             "asm89/stack-cors": "~v2.1.1",
             "composer/semver": "~3.3.2",
             "doctrine/annotations": "~1.14.3",
    diff --git a/composer/Metapackage/PinnedDevDependencies/composer.json b/composer/Metapackage/PinnedDevDependencies/composer.json
    index b3e75da8bf..34469505df 100644
    --- a/composer/Metapackage/PinnedDevDependencies/composer.json
    +++ b/composer/Metapackage/PinnedDevDependencies/composer.json
    @@ -7,7 +7,7 @@
             "webflo/drupal-core-require-dev": "*"
         },
         "require": {
    -        "drupal/core": "10.1.x-dev",
    +        "drupal/core": "11.x-dev",
             "behat/mink": "v1.10.0",
             "behat/mink-browserkit-driver": "v2.1.0",
             "behat/mink-selenium2-driver": "v1.6.0",
    diff --git a/composer/Template/LegacyProject/composer.json b/composer/Template/LegacyProject/composer.json
    index 7480cb6db4..bff6c2e152 100644
    --- a/composer/Template/LegacyProject/composer.json
    +++ b/composer/Template/LegacyProject/composer.json
    @@ -16,13 +16,13 @@
         ],
         "require": {
             "composer/installers": "^2.0",
    -        "drupal/core-composer-scaffold": "^10.1",
    -        "drupal/core-project-message": "^10.1",
    -        "drupal/core-recommended": "^10.1",
    -        "drupal/core-vendor-hardening": "^10.1"
    +        "drupal/core-composer-scaffold": "^11",
    +        "drupal/core-project-message": "^11",
    +        "drupal/core-recommended": "^11",
    +        "drupal/core-vendor-hardening": "^11"
         },
         "require-dev": {
    -        "drupal/core-dev": "^10.1"
    +        "drupal/core-dev": "^11"
         },
         "conflict": {
             "drupal/drupal": "*"
    diff --git a/composer/Template/RecommendedProject/composer.json b/composer/Template/RecommendedProject/composer.json
    index c2062229f0..26c60e1cac 100644
    --- a/composer/Template/RecommendedProject/composer.json
    +++ b/composer/Template/RecommendedProject/composer.json
    @@ -16,12 +16,12 @@
         ],
         "require": {
             "composer/installers": "^2.0",
    -        "drupal/core-composer-scaffold": "^10.1",
    -        "drupal/core-project-message": "^10.1",
    -        "drupal/core-recommended": "^10.1"
    +        "drupal/core-composer-scaffold": "^11",
    +        "drupal/core-project-message": "^11",
    +        "drupal/core-recommended": "^11"
         },
         "require-dev": {
    -        "drupal/core-dev": "^10.1"
    +        "drupal/core-dev": "^11"
         },
         "conflict": {
             "drupal/drupal": "*"
    diff --git a/core/lib/Drupal.php b/core/lib/Drupal.php
    index e15df7f7ab..cb51a509fc 100644
    --- a/core/lib/Drupal.php
    +++ b/core/lib/Drupal.php
    @@ -75,7 +75,7 @@ class Drupal {
       /**
        * The current system version.
        */
    -  const VERSION = '10.1.0-dev';
    +  const VERSION = '11.0-dev';
     
       /**
        * Core API compatibility.
    diff --git a/core/lib/Drupal/Component/Annotation/composer.json b/core/lib/Drupal/Component/Annotation/composer.json
    index a7ddbf2b67..feabe9279f 100644
    --- a/core/lib/Drupal/Component/Annotation/composer.json
    +++ b/core/lib/Drupal/Component/Annotation/composer.json
    @@ -9,9 +9,9 @@
         "require": {
             "php": ">=8.1.0",
             "doctrine/annotations": "^1.14",
    -        "drupal/core-file-cache": "10.1.x-dev",
    -        "drupal/core-plugin": "10.1.x-dev",
    -        "drupal/core-utility": "10.1.x-dev"
    +        "drupal/core-file-cache": "11.x-dev",
    +        "drupal/core-plugin": "11.x-dev",
    +        "drupal/core-utility": "11.x-dev"
         },
         "autoload": {
             "psr-4": {
    diff --git a/core/lib/Drupal/Component/Datetime/composer.json b/core/lib/Drupal/Component/Datetime/composer.json
    index 7a1429803d..91bd608f55 100644
    --- a/core/lib/Drupal/Component/Datetime/composer.json
    +++ b/core/lib/Drupal/Component/Datetime/composer.json
    @@ -8,7 +8,7 @@
         "license": "GPL-2.0-or-later",
         "require": {
             "php": ">=8.1.0",
    -        "drupal/core-utility": "10.1.x-dev"
    +        "drupal/core-utility": "11.x-dev"
         },
         "autoload": {
             "psr-4": {
    diff --git a/core/lib/Drupal/Component/Discovery/composer.json b/core/lib/Drupal/Component/Discovery/composer.json
    index 5d3ea3487c..4a93439676 100644
    --- a/core/lib/Drupal/Component/Discovery/composer.json
    +++ b/core/lib/Drupal/Component/Discovery/composer.json
    @@ -8,8 +8,8 @@
         "license": "GPL-2.0-or-later",
         "require": {
             "php": ">=8.1.0",
    -        "drupal/core-file-cache": "10.1.x-dev",
    -        "drupal/core-serialization": "10.1.x-dev"
    +        "drupal/core-file-cache": "11.x-dev",
    +        "drupal/core-serialization": "11.x-dev"
         },
         "autoload": {
             "psr-4": {
    diff --git a/core/lib/Drupal/Component/FrontMatter/composer.json b/core/lib/Drupal/Component/FrontMatter/composer.json
    index 2fc1da7a75..9baa12c9d9 100644
    --- a/core/lib/Drupal/Component/FrontMatter/composer.json
    +++ b/core/lib/Drupal/Component/FrontMatter/composer.json
    @@ -8,7 +8,7 @@
         "license": "GPL-2.0-or-later",
         "require": {
             "php": ">=8.1.0",
    -        "drupal/core-serialization": "10.1.x-dev"
    +        "drupal/core-serialization": "11.x-dev"
         },
         "autoload": {
             "psr-4": {
    diff --git a/core/lib/Drupal/Component/Gettext/composer.json b/core/lib/Drupal/Component/Gettext/composer.json
    index 9b6a7f3e8b..0db3a4bc30 100644
    --- a/core/lib/Drupal/Component/Gettext/composer.json
    +++ b/core/lib/Drupal/Component/Gettext/composer.json
    @@ -9,7 +9,7 @@
         },
         "require": {
             "php": ">=8.1.0",
    -        "drupal/core-render": "10.1.x-dev"
    +        "drupal/core-render": "11.x-dev"
         },
         "autoload": {
             "psr-4": {
    diff --git a/core/lib/Drupal/Component/PhpStorage/composer.json b/core/lib/Drupal/Component/PhpStorage/composer.json
    index 603314d00f..0517f06b0e 100644
    --- a/core/lib/Drupal/Component/PhpStorage/composer.json
    +++ b/core/lib/Drupal/Component/PhpStorage/composer.json
    @@ -8,7 +8,7 @@
         "license": "GPL-2.0-or-later",
         "require": {
             "php": ">=8.1.0",
    -        "drupal/core-file-security": "10.1.x-dev"
    +        "drupal/core-file-security": "11.x-dev"
         },
         "autoload": {
             "psr-4": {
    diff --git a/core/lib/Drupal/Component/Render/composer.json b/core/lib/Drupal/Component/Render/composer.json
    index ba1f47c04b..338eb5135b 100644
    --- a/core/lib/Drupal/Component/Render/composer.json
    +++ b/core/lib/Drupal/Component/Render/composer.json
    @@ -8,7 +8,7 @@
         "license": "GPL-2.0-or-later",
         "require": {
             "php": ">=8.1.0",
    -        "drupal/core-utility": "10.1.x-dev"
    +        "drupal/core-utility": "11.x-dev"
         },
         "autoload": {
             "psr-4": {
    

    However, there are four build test failures that might indicate some missed things:

    [ayrton:core | Tue 13:46:38] $ ../vendor/phpunit/phpunit/phpunit /Users/xjm/git/drupal/core/tests/Drupal/BuildTests
    PHPUnit 9.5.28 by Sebastian Bergmann and contributors.
    
    Testing /Users/xjm/git/drupal/core/tests/Drupal/BuildTests
    .....F..FF........F.............................................. 65 / 79 ( 82%)
    ..............                                                    79 / 79 (100%)
    
    Time: 07:38.083, Memory: 46.50 MB
    
    There were 4 failures:
    
    1) Drupal\BuildTests\Composer\Component\ComponentsIsolatedBuildTest::testComponentComposerJson with data set #5 ('/Discovery')
    COMMAND: composer install --working-dir=/private/tmp/build_workspace_7f4b10b4c8f9b864a8452f8ef72fec774R4BAF/core/lib/Drupal/Component/Discovery --no-interaction --no-progress
    OUTPUT: 
    ERROR: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
    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-file-cache 11.x-dev, found drupal/core-file-cache[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
      Problem 2
        - Root composer.json requires drupal/core-serialization 11.x-dev, found drupal/core-serialization[8.1.0, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
    
    
    
    Failed asserting that 2 matches expected 0.
    
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:317
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:304
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php:61
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:653
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:144
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:97
    
    2) Drupal\BuildTests\Composer\Component\ComponentsIsolatedBuildTest::testComponentComposerJson with data set #8 ('/FrontMatter')
    COMMAND: composer install --working-dir=/private/tmp/build_workspace_bb8eeb84067ffabe2f4626cca01f4807FnrZpQ/core/lib/Drupal/Component/FrontMatter --no-interaction --no-progress
    OUTPUT: 
    ERROR: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
    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-serialization 11.x-dev, found drupal/core-serialization[8.1.0, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
    
    
    
    Failed asserting that 2 matches expected 0.
    
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:317
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:304
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php:61
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:653
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:144
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:97
    
    3) Drupal\BuildTests\Composer\Component\ComponentsIsolatedBuildTest::testComponentComposerJson with data set #9 ('/Annotation')
    COMMAND: composer install --working-dir=/private/tmp/build_workspace_318bb98396124425e7c6992249bdba07ZE4HMO/core/lib/Drupal/Component/Annotation --no-interaction --no-progress
    OUTPUT: 
    ERROR: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
    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-file-cache 11.x-dev, found drupal/core-file-cache[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
      Problem 2
        - Root composer.json requires drupal/core-plugin 11.x-dev, found drupal/core-plugin[8.0.0-beta10, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
    
    
    
    Failed asserting that 2 matches expected 0.
    
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:317
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:304
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php:61
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:653
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:144
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:97
    
    4) Drupal\BuildTests\Composer\Component\ComponentsIsolatedBuildTest::testComponentComposerJson with data set #18 ('/PhpStorage')
    COMMAND: composer install --working-dir=/private/tmp/build_workspace_b59cf399331f02bfb642cd6794a51425P2d79p/core/lib/Drupal/Component/PhpStorage --no-interaction --no-progress
    OUTPUT: 
    ERROR: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
    Loading composer repositories with package information
    Info from https://repo.packagist.org: #StandWithUkraine
    Updating dependencies
    Your requirements could not be resolved to an installable set of packages.
    
      Problem 1
        - Root composer.json requires drupal/core-file-security 11.x-dev, found drupal/core-file-security[8.8.0-alpha1, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
    
    
    
    Failed asserting that 2 matches expected 0.
    
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:317
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:304
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php:61
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:653
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:144
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:97
    
    FAILURES!
    Tests: 79, Assertions: 529, Failures: 4.
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    I confirmed the above test failures would happen for a hypothetical 10.2.x branch also, so it does not seem to be related to the branch naming:

    [ayrton:core | Tue 14:08:41] $ ../vendor/phpunit/phpunit/phpunit /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/
    PHPUnit 9.5.28 by Sebastian Bergmann and contributors.
    
    Testing /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer
    .....F..FF........F.............................................. 65 / 66 ( 98%)
    .                                                                 66 / 66 (100%)
    
    Time: 06:35.400, Memory: 38.50 MB
    
    There were 4 failures:
    
    1) Drupal\BuildTests\Composer\Component\ComponentsIsolatedBuildTest::testComponentComposerJson with data set #5 ('/Discovery')
    COMMAND: composer install --working-dir=/private/tmp/build_workspace_9d6519750c8ad190d98609cf4aa63cb0uQZpRW/core/lib/Drupal/Component/Discovery --no-interaction --no-progress
    OUTPUT: 
    ERROR: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
    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-file-cache 10.2.x-dev, found drupal/core-file-cache[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
      Problem 2
        - Root composer.json requires drupal/core-serialization 10.2.x-dev, found drupal/core-serialization[8.1.0, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
    
    
    
    Failed asserting that 2 matches expected 0.
    
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:317
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:304
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php:61
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:653
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:144
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:97
    
    2) Drupal\BuildTests\Composer\Component\ComponentsIsolatedBuildTest::testComponentComposerJson with data set #8 ('/FrontMatter')
    COMMAND: composer install --working-dir=/private/tmp/build_workspace_56adf0f038caff10b9b5eaaaa5f8551fEx0clk/core/lib/Drupal/Component/FrontMatter --no-interaction --no-progress
    OUTPUT: 
    ERROR: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
    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-serialization 10.2.x-dev, found drupal/core-serialization[8.1.0, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
    
    
    
    Failed asserting that 2 matches expected 0.
    
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:317
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:304
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php:61
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:653
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:144
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:97
    
    3) Drupal\BuildTests\Composer\Component\ComponentsIsolatedBuildTest::testComponentComposerJson with data set #9 ('/Annotation')
    COMMAND: composer install --working-dir=/private/tmp/build_workspace_7f6dc58ef17b7f9483d5c1d748f9974dwvqudS/core/lib/Drupal/Component/Annotation --no-interaction --no-progress
    OUTPUT: 
    ERROR: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
    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-file-cache 10.2.x-dev, found drupal/core-file-cache[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
      Problem 2
        - Root composer.json requires drupal/core-plugin 10.2.x-dev, found drupal/core-plugin[8.0.0-beta10, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
    
    
    
    Failed asserting that 2 matches expected 0.
    
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:317
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:304
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php:61
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:653
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:144
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:97
    
    4) Drupal\BuildTests\Composer\Component\ComponentsIsolatedBuildTest::testComponentComposerJson with data set #18 ('/PhpStorage')
    COMMAND: composer install --working-dir=/private/tmp/build_workspace_c82516125644e242755c2d2d213044d5yVCxVt/core/lib/Drupal/Component/PhpStorage --no-interaction --no-progress
    OUTPUT: 
    ERROR: No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
    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-file-security 10.2.x-dev, found drupal/core-file-security[8.8.0-alpha1, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev, 10.0.0-alpha1, ..., 10.1.x-dev] but it does not match the constraint.
    
    
    
    Failed asserting that 2 matches expected 0.
    
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:317
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Framework/BuildTestBase.php:304
    /Users/xjm/git/drupal/core/tests/Drupal/BuildTests/Composer/Component/ComponentsIsolatedBuildTest.php:61
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/Framework/TestSuite.php:675
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:653
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:144
    /Users/xjm/git/drupal/vendor/phpunit/phpunit/src/TextUI/Command.php:97
    
    FAILURES!
    Tests: 66, Assertions: 431, Failures: 4.
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    Discussed this more with @longwave and while he's concerned it will introduce additional work, he's not concerned enough to want to stop us trying to do it - I think both me and @xjm are strongly in favour of branching 11.x instead of 10.2.x and seeing how it goes from there, so let's try to do it.

  • Status changed to RTBC about 1 year ago
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    Tried to update the issue summary to describe the new plan. Also we're planning to go ahead with this so RTBCing for more visibility.

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance andypost

    Will it be mentioned at 10.1 release notes or can go ordinary CR?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @andypost I think we will do a d.o announcement for this one since it's not really a code change as such, only affects core developers.

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly mondrake ๐Ÿ‡ฎ๐Ÿ‡น

    Just to understand, sorry did not go through the entire issue: the idea is that devs can contribute 10.2.x patches/MR in a 11.x branch, and at the time 10.2.0-alpha1 will be released, will be released out of the 11.x branch? Until we can have a 'main' branch in place of the '11.x' one?

    And - how will we work on the 'real' 11.0 to e.g. cleanup deprecations that will have though to stay in a 10.x version?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @mondrake:

    Yes for 10.x.x releases everything goes to 11.x, and we branch off minor branches when we start releases for that branch. This is the weirdest bit of the interim idea.

    For 11.x I'll try to expand a bit:

    Let's say 10.4.x and 11.0.x are going to be released on the same day.

    Once we want to commit 11.x-only patches (deprecation removals, Symfony 7 etc.), we would branch 10.4.x.

    Then we can commit 11.x-only patches to 11.x, and cherry-pick/backport 10.x-eligible changes to 10.4.x

    Once we're ready to tag 11.0.0-alpha1, we would branch 11.0.x too. At that point, we have 11.x, 11.0.x and 10.4.x branches (and 10.3.x too of course), and patches that can only land in 11.1.x stay on the 11.x branch.

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly mondrake ๐Ÿ‡ฎ๐Ÿ‡น

    Aha, ok, got it now. Thanks for clarifying @catch!

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    FWIW, I think a CR would be helpful here. There are still a lot of folks who try to contribute to core. ๐Ÿ˜… In practice, this change will impact many more people than most of the things we put out CRs for already.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @dww yeah that probably makes sense just in case people are more likely to read the CR than the post - we have the beginnings of a draft blog post for this, will link to that here so we can copy text over rather than duplicate effort between the post and the CR.

  • ๐Ÿ‡ณ๐Ÿ‡ฟNew Zealand quietone New Zealand

    I've add a task for documentation changes. I have not looked at what might need a change but I was working on ๐ŸŒฑ [policy, no patch] Merge request policy questions Fixed which made me think of docs.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    Branched 11.x, opened an issue for test failures ๐Ÿ› Resolve test failures on 11.x branch Fixed

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    Announcement post is out - we can probably copy and paste this into a change record, or have a short change record with a link:

    https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... โ†’

  • ๐Ÿ‡ญ๐Ÿ‡บHungary Gรกbor Hojtsy Hungary

    Added a short change record at https://www.drupal.org/node/3359338 โ†’ with link to the post. This part of the remaining tasks still remain:

    Documentation changes, including wiki pages and policy

  • ๐Ÿ‡ญ๐Ÿ‡บHungary Gรกbor Hojtsy Hungary
  • ๐Ÿ‡ท๐Ÿ‡บRussia Chi

    What core_version_requirement do I need in order install a module on dev version of Drupal 10?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @Chi that's the main annoyance we've introduced here, possible solution in ๐Ÿ“Œ Add a branch alias for 11.x Fixed which doesn't quite work yet though.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    Is RTBC the right status for this? We still need an actual main at some point; 11.x is just an intermediate workaround for d.o. We should either move this back, or open a followup. Possibly the latter since this issue is already long and represents lots of completed work?

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    @quietone updated both of the docs pages mentioned in #36 a couple of weeks back, I think that was the last remaining thing to marking this first step fixed and everything else that comes up can be follow-ups now.

    ๐Ÿ“Œ Add a branch alias for 11.x Fixed is probably the most urgent follow-up at the moment since it would remove some annoyances.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States xjm

    I think we should move the scope of having a main branch to a follow up, and mark this fixed.

  • Status changed to Fixed 10 months ago
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    I also think this can be marked fixed.

    We have loose-ends still around from ๐Ÿ“Œ Add another branch alias for 11.x Fixed , however we'd have exactly the same issue with a 'main' branch, and there's a last-ditch option to branch 10.2.x early.

    I opened ๐ŸŒฑ Use a 'main' branch as the development target Active .

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

  • Status changed to Fixed 10 months ago
  • ๐Ÿ‡ณ๐Ÿ‡ฟNew Zealand quietone New Zealand

    The follow up was made in #40

Production build 0.69.0 2024