+1 for 2nd approach. We can omit those frozen branches and maintain only active branches.
Thanks, Matt On Fri, Jan 27, 2017 at 10:16 AM, Sanjay Pujare <san...@datatorrent.com> wrote: > A strong +1 for the second approach for the reasons Pramod mentioned. > > Is it also possible to “prune” branches so that we have less of this > activity of merging fixes across branches? If we can ascertain that a > certain branch is not used by any user/customer (by asking in the > community) we should be able to remove it. For example, apex-malhar has > release-3.6 which is definitely required but 3 year old branches like > release-0.8.5, release-0.9.0, … telecom most probably are not being used by > anybody. > > On 1/27/17, 8:43 AM, "Pramod Immaneni" <pra...@datatorrent.com> wrote: > > 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 > > > >
