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
