Backport policy

Guidelines

Keep development where it will get the most attention. Core developers focus on the main development trunk. This is especially true for those who are formal or informal gatekeepers for an area of core. 

Limit the active issue queues of previous stable versions to changes going through the backport process.

Ensure changes are tested on the main development truck, the 'unstable' version of core. This usually gives a bit more time to find inadvertent bugs or other introduced side-effects.

Procedures

The target version for issues is the primary development trunk, 'main'.

The version is changed when the issue has been committed to main and it enters the backport process.

Committers commit changes to the main development trunk. The commit is then cherry-picked back to the stable branch(es). This ensures that there are no regressions from minor release to minor release.

Most changes that are allowed in patch releases can be cherry-picked between minor versions. Committers apply changes according to the guide to allowed changes during Drupal release cycles.

Core committers may decide to commit a bug fix only to the main development trunk, to avoid the risk of disruption in patch releases.

For more information see Introducing the main branch for Drupal core