Last updated October 10, 2011.
All proposed changes to Drupal core should be posted against the current development version (currently Drupal 8). This includes issues that were originally opened against previous versions - even if the original target was Drupal 6 or Drupal 7, once 8.x development starts, this is the target version for every change.
Bugs that occur in a stable branch of Drupal core (Drupal 6 or 7) but also occur in the development branch should be posted to the Drupal 8 issue queue with the "needs backport to D6" and/or "needs backport to D7" issue tags applied. When working on a Drupal 8 issue with one of these tags, the focus should be on finding a minimal fix that can be quickly committed to Drupal 8 and backported to the stable releases.
Sometimes, the ideal way to fix the bug in Drupal 8 may involve far-reaching changes or refactoring that would not be appropriate to backport. In those cases, it is best to create a separate Drupal 8 issue for the refactoring and cross-link it to the original issue. This allows the minimal fix to be committed to Drupal 8 and backported as quickly as possible, while work on the more far-reaching fix for Drupal 8 can continue at its own pace.
If the refactoring required for the correct fix in Drupal 8 is sufficiently important (for example, if there is agreement that the temporary fix would lead to a significant amount of confusion and technical debt if it were to remain in the codebase), the Drupal 8 issue can be created as a task and marked major (or, in rare cases, critical). This will make it count towards the core issue count thresholds and therefore will allow it to be prioritized for fixing.
Why do we do it like this?
- Applying fixes to 8.x and backporting them, ensures that when 8.0 is released, it will have all the bug fixes that have made it into 7.x (and 6.x). Conversely, if fixes are applied to the most recent supported version, there is no guarantee that they could be forward ported to Drupal 8 in a timely manner - resulting in regressions when the new version is released.
- The focus of core developers, especially those who are formal or informal gatekeepers for particular areas of core, is always on the current development version. Therefore patches against 8.x will get more attention than those against 7.x or 6.x.
- The issue queues of stable versions should be limited to patches going through the backport process, 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.
- Security patches are worked on in private, and are usually applied to the current stable versions first then forward ported. These patches happen completely outside the normal commit workflow by a small team, forward porting however can happen in the public issue queue for 8.x (since there is no security support for development releases).
- Occasionally code will change so drastically in the current development release compared to previous versions, that a fix needed for 7.x or 6.x, may not be needed for 8.x (because the functionality was refactored or removed). In those cases, the patch should be posted against the highest possible version it applies to. Note that this only usually happens towards the middle or end of release cycles - all new releases start off the same as the previous one.
Note that even if you disagree with this, and think that posting patches against the current stable release will get them fixed faster, this will have the opposite effect:
- Patch reviewers generally will not check the issue queues of the current stable release, since this should only be used for backports
- Core committers will not commit patches to the 'wrong' version, so eventually your patch will have to be moved up to the latest development release anyway
- Having outstanding issues divided into two different issue queues means there is a much higher chance for duplicate, overlapping or conflicting work - since it becomes twice as hard to find everything.
For more information on the history and rationale behind the current policy, see(the issue in which this was discussed and agreed upon).
Intention of the backport policy
While the exact policies of backporting might change in the future, there are a few issues that need to be kept in mind no matter what. The main one is Don't break (known) existing contrib modules and themes or (unknown to us) potentially existing custom modules and themes.
- Don't break the API.
- Any change in HTML or CSS can interfere with custom CSS from custom themes and modules.
- It is usually safe to introduce new hooks or new options, as long as the default behavior remains unchanged. Still, the current backport policy does only allow this if it is for a bug fix (which in most cases it is not).
- Don't let a current version be ahead (in features) of a future version. In other words, don't introduce regressions by adding features or bugfixes to earlier versions of Drupal before later ones.