Contrib.social

[policy, no patch] Update patch backporting workflow to be compatible with semantic versioning

Open on Drupal.org →
Created on 25 November 2015, over 9 years ago
Updated 21 April 2025, 3 months ago

Problem/Motivation

For many years we have used a Backport Policy → workflow: an issue should first be fixed for the latest version of Drupal, and then backported to older versions. This ensured that the latest version always contains all the fixes, but it was also the source of much confusion (ref. #2462101: [policy, no patch] Update backport policy to account for 8.x minor versions and 7.x divergence → ).

Historically this has served us very well. We only had new releases every couple of years, and between releases the code base was changed heavily, and we consciously broke backwards compatibility. Every historical branch up to 8.0.x diverged completely from its predecessor.

Now that we have adopted semantic versioning and the 8.1.x branch has been opened we are faced with a new reality. Releases will occur much more frequently, and minor releases are going to be (mostly) forwards compatible. The old backport policy doesn't work well in this scenario. If we maintain the current workflow for bugfixes and non-disruptive feature additions we now have to:

  1. Commit the fix / non-disruptive feature addition to 8.1.x
  2. Cherry-pick the commit into 8.0.x. We cannot merge back since this would introduce unwanted 8.1.x-only commits into 8.0.x

Unfortunately using cherry-pick causes the 8.0.x and 8.1.x branches to diverge. This breaks the fundamental tree model of git. In the past this wasn't so much of a problem, but with semantic versioning the 8.1.x (and later) branches should contain all fixes that were done to 8.0.x. In git's tree model this would mean that 8.0.x is an ancestor of 8.1.x. Only in the next major 9.0.x release we can introduce huge changes that will cause 9.0.x to diverge from 8.x.x.

By allowing minor branches to diverge a single bug fix will be present under two different SHA IDs in the git tree. We can no longer use git log 8.0.x..8.1.x to check which commits are present in 8.1.x but not in 8.0.x. We cannot use git branch --contains 1234abc to see if a certain important bugfix in 8.3.x is also present in 8.0.x. Basically we can no longer trust the results we get from the git history. In modern development workflows (e.g. using Continuous Integration) scripts are used that rely on basic git history operations and these will no longer be accurate.

The current backport policy is also incompatible with the concept of per-issue git branches which is planned in #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces → . If we would commit a bugfix first to 8.1.x using a per-issue git branch, and then backport it to 8.0.x the entire history of 8.1.x would end up in 8.0.x.

Proposed resolution

Using the current branches 8.0.x and 8.1.x as examples:

Proposed workflow for bugfixes:

  • Should be rolled against 8.0.x.
  • Should be committed to 8.0.x and then merged into 8.1.x, ensuring that only a single SHA exists for the commit.
  • Bugfixes are typically small and should have a minimal impact on the code base, keeping potential merge conflicts to a minimum. But conflicts will eventually occur. We need to discuss how to deal with them. Who should solve them? Separate patches? Followups?
  • After the process is completed for 8.0.x and 8.1.x we optionally can backport to 7.x, in the same way we do it now.

Proposed workflow for non BC-breaking feature additions:

  • Rolled against 8.1.x.
  • Will not be backported to 8.0.x. Site owners are expected to update to the next minor version when it is released.
  • After the process is completed for 8.1.x it can optionally be backported to 7.x.
🌱 Plan
Status

Postponed: needs info

Version

11.0 🔥

Component

other

Created by

🇧🇬Bulgaria pfrenssen Sofia

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.

  • Comment 3 months ago →
    🇳🇿New Zealand quietone

    It has been almost 10 years since there was discussion here. Is there need for discussion or shall we continue with the current workflow?

    If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

  • Comment 3 months ago →
    🇬🇧United Kingdom catch

    The two changes since this was opened are we have the 11.x 'fake main' branch open, which always gets the first commit, then release branches for minor branches, and that we keep the previous major branch open longer.

    The 11.x/main branch never changes as a target (except maybe once more when we change to actually use 'main'). This massively reduces churn in MR targets and makes long running issues (anything longer than four months) much less work to manage.

    There are a _lot_ of commits that don't cleanly cherry pick even from e.g. 11.x to 11.1.x and this isn't because the bugs change lots of code but because other issues have - test refactors, OOP hook conversions, coding standards changes etc. and additionally there are a lot of considerations about which issues get backported or not - bug fixes with API changes or upgrade paths generally won't get backported at all.

    Expecting people to figure which branch to target for the initial MR is unreasonable IMO, it is almost impossible to tell when starting work on a bugfix whether it will land in 10.4.x, 10.5.x, 11.1.x or 11.x and having to maintain multiple MRs or change the target around constantly would add loads of work.

    So I think this should be won't fix.

  • Comment about 2 months ago →
    🇳🇿New Zealand quietone

    @catch, thank you for a comprehensive comment.

    Based on catch's comment, which I also agree with, I am closing this issue as recommended.

    If there is more to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

  • Status changed to Closed: won't fix 12 days ago
  • Comment 12 days ago →
    🇳🇿New Zealand quietone
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024