apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjay Pujare <san...@datatorrent.com>
Subject Re: [DISCUSS] Policy for patches
Date Fri, 27 Jan 2017 18:16:53 GMT
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" <pramod@datatorrent.com> wrote:

    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
    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.

View raw message