Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would consider it the responsibility of the branch maintenance developer to merge the appropriate change into the current state of the trunk. There are several possibilities:</p> <ol> <li>The code in the trunk has not changed and the patch applies without conflict.</li> <li>The code in the trunk has changed and the patch applies, but with a manual merge needed.</li> <li>The code in the trunk has completely changed and the patch cannot apply. The developer must evaluate whether the same defect exists in the trunk, and apply an equivalent fix if needed.</li> </ol> <p>Cases 1 and 2 are the usual maintenance development paths. Case 3 is the case you are considering, where the trunk code cannot accept the maintenance patch in any form. If the developer cannot himself determine whether the same problem might exist in the trunk, then he should enter an issue into the issue tracking system. This issue would direct the trunk developers to consider the reason for the patch in the maintenance branch and whether the same defect might still exist. Entering a new issue for a <em>possible</em> defect in the trunk should be a last resort for the maintenance developer.</p> <p>One benefit of having maintenance developers try to apply patches to the updated trunk is to increase their familiarity with the new code base. Eventually, they will run out of maintenance work and will need to work with the new trunk. Having at least a basic level of familiarity will be of great benefit.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload