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:
- Commit the fix / non-disruptive feature addition to 8.1.x
- 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.