Backport Management

Introduction

This document talk about how to manage backports, a backport is a fix that needs to be done in a release already published, different of the latest one.

As general rule we publish new versions of the releases starting from the last CS one, and including all the QAA.

How to create backports

The most important field in a backport is the target_version, you should ensure to have it filled and updated as needed

• Create an issue of type "defect", following our Bug Reporting Guidelines .
• When moving the defect to status "scheduled" in mantis, mark the release or releases (the list accept multiple select) where backport is required.
• This will create as many copies of the defect as backports are required, filling in each one the target_version field.
• Manage each backport individually. First step here is to check whether the issue is valid in PI or it is just intended to fix a previous release. In the latter case, the defect should be rejected as "no change required" and the follow up kept in the backport(s) themselves.

Flow for regressions

Say regression found in 14Q3 (supposing PI is 15Q2) and note that for 14Q4 we are not going to publish any update.

• Step 1: Reporter creates one defect for PI 15Q2 and sends a mail to release.management list
• Step 2: Developer analyze the issue and discover that is needed to create two backports for 15Q1.2 (QAA) and 14Q3.8 (CS). Each backport will have filled the target version with 15Q1.2 and 14Q3.8 respectively by the script that creates the backports.
• Step 3: The developer will approve with the Team Lead the creation of backports, will create them, will update the regression with the available at the moment information (Regression Fields and Caused By link) and will send a mail to release.management list with regression confirmation (or not).
  • Note: If Team Lead has doubts in backports approval (risk-value, cost-value), he/she escalates it to the Product SW Engineering Manager.
• Step 4: Developer will fix the defect in PI and the backports in repos 3.0PR15Q1.2 and 3.0PR14Q3.8. The repos for emergencies will be available here:
  • code.openbravo.com/erp/backports/
  • code.openbravo.com/retail/backports/
  • Note: if clear that will enter in the release it is fine to do the push of the issue before the approval.
• Step 5: Every backport must be checked by a person different of the developer that has do the fix (like a normal issue):
  • tested in the backport repository
  • reviewed in the backport repository
  • checked that are in the correct repo
  • checked that the target_version is correct
  • checked that all Regression Fields and Caused By link are filled in
  • checked that commit message clearly describes regression fix which normally means explaining what was wrong in the changeset that introduced it.
• Step 6: Dmitry will trigger the package of the emergency release
• Step 7: RM before doing the package will check that all the issues are closed and have the approved tag, by selecting the backports by its target version.

Please note

• All backports have to be related to a defect since backports are not taken into account for metrics
• Other than the relationship added by Mantis, the defect life cycle will be independent for each backport.
• If the release requiring the backport is not in the list when scheduling, you have to request it by sending an email to staff.rm
• Overriding the process by manually creating an issue with backport type and adding a relation to the original defect is an error prone task that we do not recommend.

FAQ

I have an issue already resolved or closed, how I create a backport of it?

It is needed to change to another status and go back to scheduled status to create the backports.

The issue only apply to x release but in pi is already fix, do I need to create an issue or only the backport?

It is needed to create the issue for pi, create the backport for release x and then the issue for pi can be rejected as "no change required"

When commiting a backport I have to put in the message the id of the issue or the id of the backport?

The commit message of a backport should have the id of the backport.

How do I transplant the changeset from pi to backport repository?

Typically the same changeset created for pi can be applied without (major) modifications in the backport branch, if this is the case, the following mercurial command can be executed in the directory where you have the backport repository clone. Note the -e param which allows to edit the message commit in order to set the id of the backport.

hg transplant -e -s pathToYourLocalPiClone changesetIdToBackport

The commit url in mantis of a backport don't work

After the publish of the emergency release the backport repository is merged to main , and the repository is deleted, so the links to the commits will stop working.

The workaround is edit the url changing "backport/3.0PRxQy.z" to "devel/main".

Example

https://code.openbravo.com/erp/backports/3.0PR14Q3.8/rev/xxxxxxx

Should be:

https://code.openbravo.com/erp/devel/main/rev/xxxxxxx

Or in the case of retail, change "retail/backports/3.0RRxQy.z" to "erp/pmods". Example

https://code.openbravo.com/retail/backports/3.0RR15Q2.1/org.openbravo.retail.posterminal/rev/xxxxxxx

Should be:

https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/xxxxxxx