Hi, I wanted to bring up the topic of patches for issues discovered in older releases and start a discussion to come up with a policy on how to apply them.
One approach is the patch gets only applied to the release it was discovered in and master. Another approach is it gets applied to all release branches >= discovered release and master. There may be other approaches as well which can come up in this discussion. The advantage of the first approach is that the immediate work is limited to a single fix and merge. The second approach requires more work initially as the patch needs to get applied to more one or more places. I am tending towards the second approach of applying the fix to all release branches >= discovered release, while also having some sort of an end of life policy for releases otherwise it might become difficult to manage the fixes. The end of life policy would mean that beyond a time period (something reasonable period between 1 - 3 years) after the release is made the release branch become frozen and no more fixes are applied to it. Consider the following two problematic scenarios if we apply the fix only to the one discovered release. - Let's say tomorrow a new fix needs to be made to a newer release branch (which had existed at the time of the fix) that is dependent on the current fix. Before applying the new fix one would need to first know to cherry-pick the old fix (may not be trivial to know this) and second and more important there could be merge conflicts when cherry-picking. At this point, you may be trying to resolve the conflicts where you may not be the primary author of the fix and/or the knowledge of the fix is no longer fresh in folks minds. This is prone to errors. - Let's call this fix a. Let's say there was another fix b. requiring a. to work correctly also on the same release branch but no compile dependencies on a. If in future we have a fix c. that depends on b. that needs to be applied on a different release branch both b. and a. would need to be cherry picked. It might be easy to figure out b. is needed, as c. has a direct dependency to it but would not be easy to determine that a. is also needed since that is old knowledge. It will not be easy to catch this omission because of no compile errors if a. is not included. Thanks
