Skip to content

Backporting Guidelines

Jump to bottom
Andrew Crosby edited this page Oct 25, 2022 · 8 revisions

Backporting to Z Streams

What Should I backport?

Changes that cannot be backported

  • Major/minor version for core backend dependencies: Major/minor version updates for our core dependencies typically come with migrations, new features, and possible breaking changes. Here is a list of dependencies that should follow these rules. Other minor dependencies can be updated if they don't break anything.
    • Pulp Core
    • Pulp Ansible
    • Pulp Container
    • Ansible
    • Django
    • Django Rest Framework
  • Migrations: database migrations can break installations and can't be backported without including all previous migrations.
  • Breaking changes to the API: breaking changes for APIs should be avoided in new releases at all costs, and if they have to be made, should never be backported. These include:
    • Removing endpoints
    • Removing fields from endpoints
    • Changing the functionality of existing endpoints
  • Significant changes to the UI: Users expect the functionality of stable releases to remain unchanged. Making major changes to the user experience breaks that expectation.

Changes that should not be backported without a good reason

  • New features: generally speaking, new features should be reserved for new releases. However, in some instances minor features may be backported if they are requested by product management as long as the don't violate any of the constraints listed above

Check Jira issue priority to see if change should be backported to specific stable branch

  • Each stable-x.y branch has a support level that changes over time per life cycle
  • Each support level gets updates based on fix severity, we mapped those to Jira priorities
  • These support levels should only get updates from Jira issues with these Jira "Priority" types
    • Full Support: Blocker, Critical, Major
    • Maintenance Support 1: Blocker, Critical
    • Maintenance Support 2: Blocker

How do I backport a PR?

Simply add the backport-x.y label to any pull request and Patchback will automatically open up a PR to cherrypick the commit to the corresponding stable-x.y branch. If there are merge conflicts, Patchback will fail an the commits will have to be backported manually. If this happens, Patchback will provide instructions on how to manually backport the commit.

Once a commit has been merged into the corresponding stable branch, please add the backported-x.y label to the original pull request to indicate that it has been backported.

See https://github.com/ansible/ansible-hub-ui/pull/422 as an example of a PR that has been backported to version 4.2 and 4.3.

Do I need reviews on backported PRs?

If patchback can backport the PR without an merge conflicts, then no reviews are required and the PR can be merged as soon as CI passes.

If there are merge conflicts, then backport PRs must be reviewed by another member of the team.

Sponsored by Red Hat, Inc.

Clone this wiki locally