Drupal Core Adopts the main Branch: A Technical Deep Dive into the New Workflow

In January 2026, the Drupal project officially announced that the main branch is now the primary development branch for Drupal core. This change completes a series of infrastructure updates that began back in 2023 and brings Drupal’s development workflow in line with modern Git best practices used across the open-source ecosystem.

This article explains:

• what exactly changed,
• why the move to main matters,
• how core development workflows are affected,
• and what contributors should do going forward.

Background: How Drupal Core Worked Before

Historically, Drupal used version-based development branches:

• 8.x → 9.x → 10.x → 11.x
• each major release introduced a new “trunk”
• issues and merge requests had to be retargeted every few years

This model created several problems:

• large-scale issue version updates with every major release
• unnecessary administrative overhead
• confusion for new contributors
• increased risk of errors during transitions

While functional, this approach no longer matched how modern large-scale open-source projects operate.

The New Model: main as a Permanent Trunk

Drupal core now follows a permanent trunk model, where:

• main is the single, long-lived development branch
• major releases are created via tags, not new trunks
• supported releases live in dedicated maintenance branches

Conceptually:

main  → future major versions (Drupal 12+)
  │
  ├── 11.x → stable / maintenance
  ├── older branches → security-only or EOL

What Lives in main

The main branch contains:

• new features
• architectural changes
• API modifications
• deprecations
• all work targeting future Drupal releases

In short:

main is the canonical source of truth for Drupal core development.

Branch Targeting Rules for Merge Requests

With this change, branch selection becomes simpler and more predictable.

Recommended Target Branches

Rule of thumb:
If the change could affect Drupal 12 or later, it belongs in main.

Forward Development and Backports

Drupal now enforces a clearer strategy:

Develop forward, backport selectively.

Typical workflow:

1. Implement and review changes in main
2. Once merged, decide whether the fix should be backported
3. Apply backports to 11.x when appropriate

Benefits:

• reduced branch divergence
• fewer merge conflicts
• clearer CI pipelines
• improved long-term maintainability

Issue Management Changes

Before

• Issues were tied to specific version numbers (11.x-dev, 10.3.x, etc.)
• Every major release required mass updates across the issue queue
• Contributors had to know which version was “current”

Now

• The default issue version is main
• Issues describe problems, not release numbers
• Version-specific targeting is used only when necessary

Drupal.org will automatically migrate most existing 11.x issues to main, removing the need for manual bulk updates.

Updating Local Git Checkouts

Developers with existing Drupal core clones should update their local setup.

If main already exists locally:

git fetch origin
git checkout main
git branch -u origin/main main

If not:

git fetch origin
git checkout -b main origin/main

Legacy workflows that treat 11.x as the default development branch are no longer recommended.

What Happens to Existing Merge Requests

GitLab will:

• automatically retarget merge requests to main

GitLab will not:

• rebase branches
• add main to issue forks automatically

This avoids unexpected conflicts or history rewrites. Contributors can rebase or update forks as part of normal MR maintenance.

Temporary allowance:

Merge requests that apply cleanly to main may still be merged even if main does not yet exist in the contributor’s fork.

Impact on Contrib Modules

This change directly affects Drupal core, not contrib projects. However, it does set a precedent.

Contrib maintainers may:

• continue using versioned branches (1.x, 2.x)
• or adopt a main-based workflow for actively developed projects

For modern, fast-moving contrib modules, adopting main as the development branch and tagging releases may simplify long-term maintenance.

Why This Matters

Technical Benefits

• simpler automation and CI/CD
• stable Git references
• reduced process overhead
• cleaner long-term branching strategy

Community Benefits

• easier onboarding for new contributors
• less manual work for maintainers
• fewer mistakes during major releases

Conclusion

The move to a permanent main branch is not a cosmetic change — it’s a foundational improvement to how Drupal core is built and maintained.

By aligning with industry-standard Git workflows, Drupal:

• reduces operational complexity,
• improves contributor experience,
• and positions itself more strongly for future major releases.

For contributors, this means:

• fewer rules to remember,
• fewer migrations to manage,
• and more focus on writing quality code.