A development organization may need to maintain multiple branches for supporting previous releases and for developing some features that have huge impacts to the stability of the codes.
We should always have a main line that is whether the branches were forked from and will be synchronized with.
A bug fix should be fixed in this main line and then
backported to the other branches as necessary. By following this practice, you can guarantee that you won't have regressions later.
Only in few cases, when the issue are not applicable any more, a fix to the old release branches is acceptable. Although the fix directly applied to the old release may be different from the codes in the main line, we can still consider this is kind of a backport, to fix an issue that is already fixed in the main line.
Providing a one-off fix on a release branch is dangerous. In addition to the risk of having a regression, you may also have the risk of forward compatibility.
We should always have a main line that is whether the branches were forked from and will be synchronized with.
A bug fix should be fixed in this main line and then
backported to the other branches as necessary. By following this practice, you can guarantee that you won't have regressions later.
Only in few cases, when the issue are not applicable any more, a fix to the old release branches is acceptable. Although the fix directly applied to the old release may be different from the codes in the main line, we can still consider this is kind of a backport, to fix an issue that is already fixed in the main line.
Providing a one-off fix on a release branch is dangerous. In addition to the risk of having a regression, you may also have the risk of forward compatibility.
No comments:
Post a Comment