Problem/Motivation

Follow-up from #3294814: [Policy] Branch Naming: Use an 11.x branch for HEAD, then use 'main' when d.o can support it. https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... has more of a write-up.

Drupal.org currently doesn't support having a 'main' branch since some logic is tied to version numbers, when it does, or when the relevant functionality is moved to gitlab, we should stop using 11.x as the development target and use main instead.

We're hoping this can happen before we need to open a '12.x' branch.

There are going to be core issues with having a non-numeric version too - we might have to solve that but setting Drupal::VERSION to the current major version target and updating that every so often (11, 12, 13 etc.)

The branching strategy would otherwise be the same as the current one with '11.x'.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3382815

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

catch created an issue. See original summary.

drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes

Tagging 11.0.0-alpha1 was a good way of spotting 2 technical blockers:

drumm opened merge request !13528

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Active » Needs review
Issue tags: +Vienna2025

I’ve been testing subtree splitting a main branch on staging. The composer.json branch alias added by the MR here was required for subtree splits to complete successfully.

drumm’s picture

drumm
he/him
Location NY, US
commented

I think I’ve taken this MR as far as I can. The approach can probably be improved to be less duplicitous.

The changes in #3445262: Update core packaging to support a main branch have not been deployed to production yet, and I am also working on one more change to the subtree splitter that is needed.

drumm’s picture

drumm
he/him
Location NY, US
commented

All changes I believe are needed in Drupal.org infrastructure are now deployed.

Getting https://git.drupalcode.org/project/drupal/-/merge_requests/13528 reviewed and merged should be the next step. I don’t think there are any disadvantages to having this change in the 11.x branch; it will be on all future branches anyway.

To test CI ahead of branching, another repository could be used.

Then I think all knowable blockers for creating a main branch might be resolved, the branch can be created, and we start looking for unanticipated things to do.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

The approach here looks good to me
For those interested here's the composer docs on branch-alias

Looks like there's a conflict on the composer.lock file now

frob’s picture

frob
Primary language English
commented

Can I ask why? Why do this?

catch’s picture

catch
he/him
Primary language English
commented

Every time we have a new major release, we have to retarget thousands of MRs (and issues) to the new major branch, e.g. 10.x to 11.x, or 11.x to 12.x.

With a 'main' branch, all issues and MRs, except for backports, will target 'main' in perpetuity.

The '11.x' branch itself was a move towards this - before we opened that, we used to have to retarget issues and MRs everything six months when a new minor branch opened, we only started using 11.x because some d.o things blocked using main, which they now don't.

longwave made their first commit to this issue’s fork.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Priority: Normal » Critical

Bumping to critical, from a release management POV we need to open a new major branch very soon. Let's try this for main first and fall back to 12.x if we run into unsolvable blockers.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Needs review » Needs work

Needs rebase first.

shalini_jha made their first commit to this issue’s fork.

quietone made their first commit to this issue’s fork.

quietone’s picture

quietone commented
Status: Needs work » Needs review

Rebase and tests passing

godotislate’s picture

godotislate
he/him
commented

One question about the plugin-api-version change in composer.lock from 2.9.0 to 2.6.0. My guess is that the changes were generated locally with composer 2.8.x or lower, but I'm not sure how much this matters.

mstrelan’s picture

mstrelan commented

Once we have main, or even 12.x, what happens to 11.x? Does it continue to receive backports to stay current with 11.4.x?

Also an observation regarding the urgency in #11 - we could probably just open 12.0.x and branch main (or 12.x) from there when we're ready. But better to try open main now anyway.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

@mstrelan the urgency is more around the issue version field on d.o which has to be bulk updated when we open a new branch, which is tedious and can only be done by the DA; if we successfully open main then hopefully we never have to do that again.

mstrelan’s picture

mstrelan commented

Good point, I realised that after I posted

catch’s picture

catch
he/him
Primary language English
commented
Status: Needs review » Needs work

Once we have main, or even 12.x, what happens to 11.x? Does it continue to receive backports to stay current with 11.4.x?

That's a good question.

For the actual 11.x branch, I think we can leave it in place, and use it as the HEAD of 11.x, so that we we only branch 11.4.x and 11.5.x when we're ready to tag beta/rc/stable releases. It means an extra branch to commit to during beta/rc but otherwise not much overhead.

Longer term I'm less sure, we don't currently have a '10.x' branch so we needed to open 10.6.x, 10.5.x etc. as soon as we got to beta of the previous minor, but we could have used a 10.x branch as 'HEAD' and then opened them only as release branches later on. However we don't need to make a firm decision on that for approximately two years when we start committing things to what will become 13.0.0 - as long as we don't mind keeping the 11.x branch around nothing else will change.

The main thing that having 11.x vs not changes in practice is backports - e.g. it would provide a stable target for a backport MR, but with backports we tend to do them either very quickly after a commit (at least within the same six month minor window), or not at all, it's rare the target branch changes during the backport process.

Needs work for the plugin API version change, we should set that back to what it was. Otherwise this looks ready to go.

For next steps, my preference would be to commit this asap, open the main branch (we'll need to let the DA know we're ready to try it), and then we can make sure that tests actually pass on the actual main branch on CI which they still might not, open issues for bulk issue updates, figure out if we can bulk update all the MR targets with a bot or start doing that manually etc (hopefully for the last time).

quietone’s picture

quietone commented
Status: Needs work » Needs review

Fixed the plugin api version. Back to needs review.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Needs review » Reviewed & tested by the community

Only change is the plugin API version, back to RTBC.

drumm’s picture

drumm
he/him
Location NY, US
commented

For the actual 11.x branch, I think we can leave it in place, and use it as the HEAD of 11.x, so that we we only branch 11.4.x and 11.5.x when we're ready to tag beta/rc/stable releases. It means an extra branch to commit to during beta/rc but otherwise not much overhead.

Yes, leave 11.x in place and keep using it. You can tag the highest 11.minor.* releases off of 11.x, and only branch when the previous minor series needs to diverge.

For next steps, my preference would be to commit this asap, open the main branch (we'll need to let the DA know we're ready to try it), and then we can make sure that tests actually pass on the actual main branch on CI which they still might not, open issues for bulk issue updates, figure out if we can bulk update all the MR targets with a bot or start doing that manually etc (hopefully for the last time).

It would be good to have a couple commits on 11.x after this is merged, then open main after we know that’s working well.

  • catch committed fe5bd78b on 11.x 
    task: #3382815 Prepare to use a 'main' branch as the development target...
catch’s picture

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 11.x, thanks!

We can definitely do a couple more commits on 11.x (or more than that) prior to actually branching main.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

catch closed merge request !13528

drumm’s picture

drumm
he/him
Location NY, US
commented

This made it through packaging with no errors or anything amiss that I can see: https://github.com/drupal/core-recommended/commit/47a79a2b24a5e7832ec26f...

Did we want this issue open for tracking all the way through main branch opening?

dww’s picture

dww
we/he/they
commented

One thing, not sure if it's for here or a new drupalorg issue, is that I don't know what project_release is going to do with all its version fields if you try to create a release node pointing to a branch called 'main'. Way, way, way back, we actually had release nodes that pointed to "HEAD". See https://www.drupal.org/node/86863 for some gory details circa 20 years ago. 😂 Lots has changed, but not everything. We might need some changes to drupalorg_project* somewhere to special case 'main' and do something creative with the underlying version_* fields so that once main exists, we can create a release node for d.o so that issues can target that version.

Or, we hurry up and migrate core to GitLab issues. 😬 But I think this ship is probably going to sail before that happens, so we're still going to have to work around the project_issue vs. project_release stuff.

drumm’s picture

drumm
he/him
Location NY, US
commented

I already tested that and made changes that should work in #3445262: Update core packaging to support a main branch

dww’s picture

dww
we/he/they
commented

@drumm re: #30: Fantastic, thanks!

nicxvan’s picture

nicxvan commented

I'm not sure where to record this, but when we are ready to retarget core MRs to main we should be able to do that programmatically:

It looks like:

glab mr update ### --target-branch main

Where ### is the number of the MR

We can get that list with this I suspect:

glab mr list --target-branch=11.x

References:
https://docs.gitlab.com/cli/mr/list/
https://docs.gitlab.com/cli/mr/update/

dww’s picture

dww
we/he/they
commented

Re: #33: that’s handy, thanks. But we’d still need the manual effort of rebasing the issue forks, etc. I’m not sure how useful bulk updating the MR metadata is without also getting the branches in Git right at the same time.

drumm’s picture

drumm
he/him
Location NY, US
commented

I haven’t spotted any packaging issues after the pushes around tagging 10.6.2 & 11.3.2, so I can’t think of any Drupal.org or infrastructure blockers for branching. Be sure to create the release for main after branching.

For MR updating, having a person’s eyes on each to generally review the issue to see if something else has changed or needs updating is useful.

catch’s picture

catch
he/him
Primary language English
commented

But we’d still need the manual effort of rebasing the issue forks, etc.

I don't think we'd need to rebase? 11.x and main will be identical at the point where they're branched. Eventually, main will diverge, but that's no different to new commits on 11.x. So it should be OK for a little while until it's not.

nicxvan’s picture

nicxvan commented

Yeah, if you're retargeting an MR to a new future branch of the original source you only need to rebase if you already needed to.

If we do this automated then it will prevent a lot of pain of realizing that 11.x was still unintentionally targeted.

Status: Fixed » Closed (fixed)

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