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

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:

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

Week of October 25, 2021

Drupal 9.3.0-alpha1 released and 9.4.x opened for development.

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

Week of October 25, 2021

Drupal 9.3.x opened for development and 9.3.0-alpha1 released

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:

Around October/November 2021, when major dependency updates are available
Drupal 10.0.x and 9.4.x branches opened for development.

Most of the preparation for Drupal 10 happens in Drupal 9 prior to this. See Add compatibility for the latest major and minor versions of dependencies to Drupal 9.

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

~~Finalize decision~~
~~Identify all places where there are hard coded assumptions about 'branch' and 'version'~~
~~Choose an appropriate transition window in an upcoming version cycle~~
Documentation changes, including wiki pages and policy

User interface changes

Release notes snippet

Comment	File	Size	Author
#11	3294814-11.feature-module-master-version.png	85.4 KB	dww

Comments

Comment #1

7 July 2022 at 18:29

hestenet created an issue. See original summary.

Comment #2

xjm

she/her

English

commented 8 July 2022 at 01:52

FWIW I'm completely in favor of this change in principle. The main issue is the implementation process and Drupal.org integration with versions, especially for project_issue, DrupalCI, and packaging.

I can tell you off the top of my head where the branch/version appears in the core codebase because it includes the places I have to resolve merge conflicts when I tag a security release:

The Drupal::VERSION constant in core/lib/Drupal.php
Three spots in composer.lock
One in each template and metapackage
version: VERSION in every core info and libraries file (but I assume that's out of scope)
Constraints related to the core version in the components (core/lib/Drupal/Component); see #3272110: Drupal 9 and 10's Drupal\Component composer.json files are totally out of date.

Most of the above are updated automatically by composer/Composer.php (or, in the case of the info files, by packaging itself).

There are also loosely related concepts like:

Update hook numbering
Drupal::CORE_COMPATIBILITY
Drupal::CORE_MINIMUM_SCHEMA_VERSION

.... but I think those can be handled independently of this change. Update hook numbering is a manual process aside from hook_update_last_removed() (which is via hook implementation, after all), and the other two still reference D8 and will probably eventually be deprecated.

What I don't know: How Composer would handle the change. Right now we have to do COMPOSER_ROOT_VERSION=10.0.x-dev composer whatever; what happens when it's main instead of 10.0.x?

Comment #3

xjm

she/her

English

commented 8 July 2022 at 02:09

Other things that might be affected:

Security advisory and update behavior on dev sites
Translations and l.d.o
Site settings hashing for dev sites (see core/lib/Drupal/Core/Site/Settings.php).

Additional specific site settings:

core/assets/scaffold/files/default.settings.php:# $settings['deployment_identifier'] = \Drupal::VERSION;
sites/default/default.settings.php:# $settings['deployment_identifier'] = \Drupal::VERSION;

Views, apparently, although this might just be for debugging:

core/modules/views/views.views_execution.inc:    '***CURRENT_VERSION***' => \Drupal::VERSION,
core/modules/views/views.api.php:    '***CURRENT_VERSION***' => \Drupal::VERSION,

Comment #4

cilefen commented 8 July 2022 at 03:51

This is the way. I recognize that it is some work. Wouldn’t the Composer version reference be dev-main?

Comment #5

xjm

she/her

English

commented 8 July 2022 at 14:12

Some of the things that might be affected in core and on Drupal.org are probably implied by what needs changes in: https://www.drupal.org/about/core/policies/maintainers/create-core-branch

Comment #6

longwave

he/him

English

commented 14 July 2022 at 10:24

FWIW Symfony does not follow this policy and does not have a main branch, rather they follow our branching scheme of just moving HEAD to the next minor/major version when the time is right.

This also has a slightly weird implication for deprecations, where we might want to say "is deprecated in drupal:11.1.0 and is removed from drupal:12.0.0" which would be committed to main and 11.1.x doesn't actually exist yet.

Comment #7

catch

he/him

English

commented 21 July 2022 at 11:53

#2 means we more or less have to do this even if there are some drawbacks. #1 is already very time consuming and confusing for everyone.

This also has a slightly weird implication for deprecations, where we might want to say "is deprecated in drupal:11.1.0 and is removed from drupal:12.0.0" which would be committed to main and 11.1.x doesn't actually exist yet.

This will take some getting used to but I think it's basically fine. We also might still have 11.1.x open by the time we're committing patches like that, but the commits would get cherry-picked from main - it doesn't specifically enforce when we open other branches just that we always have main open.

Comment #8

dww

we/he/they

commented 13 March 2023 at 21:03

Status:

Active

» Needs review

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

Comment #9

drumm

he/him

NY, US

commented 14 March 2023 at 18:59

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.

Comment #10

dww

we/he/they

commented 14 March 2023 at 19:03

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.

Comment #11

dww

we/he/they

commented 14 March 2023 at 19:41

Status	File	Size
new	3294814-11.feature-module-master-version.png	85.4 KB

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

version selector with 'master' [sic] branch option

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

Comment #12

drumm

he/him

NY, US

commented 14 March 2023 at 19:48

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.

Comment #13

pasqualle

🇭🇺 Budapest

commented 21 March 2023 at 08:55

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.

Comment #14

catch

he/him

English

commented 21 March 2023 at 09:26

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

Comment #15

catch

he/him

English

commented 23 March 2023 at 17:31

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.

Comment #16

xjm

she/her

English

commented 23 March 2023 at 17:34

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

Comment #17

xjm

she/her

English

commented 18 April 2023 at 18:57

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.

Comment #18

xjm

she/her

English

commented 18 April 2023 at 19:29

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.

Comment #19

catch

he/him

English

commented 3 May 2023 at 17:11

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.

Comment #20

catch

he/him

English

commented 5 May 2023 at 12:35

Title:	[Policy] Branch Naming: Convert from version-specific to 'main' dev branch	» [Policy] Branch Naming: Use an 11.x branch for HEAD, then use 'main' when d.o can support it
Priority:	Normal	» Major
Issue summary:	View changes
Status:	Needs review	» Reviewed & tested by the community

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.

Comment #21

andypost

he/him

Russian

commented 5 May 2023 at 12:56

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

Comment #22

catch

he/him

English

commented 5 May 2023 at 13:01

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

Comment #23

mondrake

🇮🇹

commented 5 May 2023 at 13:45

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?

Comment #24

catch

he/him

English

commented 5 May 2023 at 14:17

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

Comment #25

mondrake

🇮🇹

commented 5 May 2023 at 14:21

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

Comment #26

dww

we/he/they

commented 6 May 2023 at 19:41

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.

Comment #27

catch

he/him

English

commented 7 May 2023 at 17:53

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

Comment #28

quietone commented 9 May 2023 at 03:08

Issue summary:

View changes

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

Comment #29

catch

he/him

English

commented 9 May 2023 at 11:39

Branched 11.x, opened an issue for test failures #3359077: Resolve test failures on 11.x branch

Comment #30

catch

he/him

English

commented 9 May 2023 at 19:00

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

Comment #31

gábor hojtsy

he/him

Hungarian

Hungary

commented 10 May 2023 at 09:54

Issue summary:	View changes
Status:	Reviewed & tested by the community	» Fixed

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

Comment #32

gábor hojtsy

he/him

Hungarian

Hungary

commented 10 May 2023 at 09:55

Status:

Fixed

» Reviewed & tested by the community

Comment #33

10 May 2023 at 09:55

Version:

10.1.x-dev

» 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #34

chi commented 24 June 2023 at 14:46

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

Comment #35

catch

he/him

English

commented 26 June 2023 at 13:55

@Chi that's the main annoyance we've introduced here, possible solution in #3364646: Add a branch alias for 11.x which doesn't quite work yet though.

Comment #36

quietone commented 27 June 2023 at 07:50

At least these policy documents need to be updated.

It is on my list to update these docs.

Comment #37

xjm

she/her

English

commented 15 July 2023 at 11:23

Issue tags:

+Needs followup

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?

Comment #38

catch

he/him

English

commented 15 July 2023 at 21:07

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

#3364646: Add a branch alias for 11.x is probably the most urgent follow-up at the moment since it would remove some annoyances.

Comment #39

xjm

she/her

English

commented 19 August 2023 at 10:39

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

Comment #40

catch

he/him

English

commented 23 August 2023 at 09:16

Status:

Reviewed & tested by the community

» Fixed

I also think this can be marked fixed.

We have loose-ends still around from #3376476: Add another branch alias for 11.x, 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 #3382815: Use a 'main' branch as the development target.