Last updated November 16, 2016.
The backport policy exists so that people working on issues can quickly see which versions a bug report or other issue should be fixed against and to avoid duplicate and unnecessary work.
Drupal 8.x minor versions
The primary target for bug fixes is the current minor branch of 8.x (i.e. if 8.1.0 is released and 8.2.x is in development, bug reports should be posted against 8.1.x by default). For feature requests the primary target is the development branch (8.2.x in the above example).
Patches will always be committed to the development minor branch (currently 8.2.x) first, and cherry-picked backwards to ensure that there are no regressions from minor release to minor release. This also ensures that the development version has as many bug fixes as possible, since the criteria for which patches are eligible is wider than for the active minor branch.
Most patches can be cherry-picked between minor core versions, so will be applied to both branches by maintainers at the same time.
Some patches may require further testing, or changes in line with the backwards compatibility policy before they can be accepted into the current minor branch. Where this is the case core committers will indicate on the issue. In some cases we may decide to commit an issue only to the development minor branch, to avoid the risk of disruption in patch releases.
Where an issue filed against 8.x also applies to 7.x, a separate issue should be opened against 7.x, related to 8.x via the 'Parent issue' field (this can be done using the "Add child issue" link on the 8.x issue). The new Drupal 7 issue should be prefixed with [D7] in the title to make it easier to distinguish it from the Drupal 8 issue. Alternatively the needs backport to D7 issue tag can be added to the parent issue to indicate that a child issue still needs to be created (but actually creating the child issue is preferred).
By default, 7.x issues should be marked postponed until the 8.x issue is fixed to avoid duplicate work. However, if there are good reasons to work on a fix independently (for example divergence between the 7.x and 8.x code bases or a different approach being needed), then the 7.x issue may be worked on and fixed independently.
Issues posted only against 7.x should have an explanation in the issue summary as to why there is no related 8.x issue (for example if they apply to a feature that was removed).
Drupal 6 is end of life, but security issues may be posted against http://drupal.org/project/d6lts
No bug reports should be posted against 9.x. There may be cases where all attempts to resolve a bug in 8.x get exhausted and the only way to resolve it is via an API break requiring a new major version, but this is something that should be discussed with framework and release managers before changing the version.
Once the 9.x branch is open for development, this policy will be updated to document the workflow for fixing issues that exist in both 8.x and 9.x. (The general goal, however, is not to hold up Drupal 8 backports on "ideal" fixes that involve far-reaching changes or refactoring that would only be appropriate for Drupal 9. Instead, the issue can usually be fixed in a minimal backportable way for Drupal 9 first, then a separate cross-linked Drupal 9 issue can be created for the far-reaching fix which can continue at its own pace.)
Why do we do it like this?
- Applying fixes to the most recent version of Drupal first and backporting them afterwards ensures that the fix won't get "lost" (and never fixed) in future releases of Drupal, and helps prevent older sites from experiencing regressions when updating to the newer version.
- The focus of core developers, especially those who are formal or informal gatekeepers for particular areas of core, is often on the current development version. Therefore patches against 8.x will usually get more attention than those against 7.x.
- The active issue queues of previous stable versions should be limited to patches going through the backport process or those which don't apply to the new version, keeping them more manageable for branch maintainers who while the release is stable are in 'maintenance mode'.
- Applying patches to the current development version gives them a window (even if it's a short one) to be tested in the 'unstable' version of core, before they are applied to the version that thousands of people are using. This gives a bit more time to find inadvertent bugs or other side-effects that may be introduced.
For more information on the history and rationale behind the current policy, see(the issue in which this was discussed and agreed upon) and (where the policy was updated for the new core release cycle).
See What patches may be added to a stable release of Drupal core? for further details.