I would feel much more comfortable if the default behavior was to always port back in reverse order without skipping a support branch. This makes it much harder to forget poring to a support branch. Few things are more frustrating to users than upgrading to a new patch release to get a bug fix and having that bug come back when they upgrade months later to a newer minor release.
There definitely should be exceptions for example when we are in the final stages of shipping a patch release on a branch, but those should be exceptions. On Fri, Aug 28, 2020 at 5:12 PM Owen Nichols <onich...@vmware.com> wrote: > Sound like there is no need to clarify or amend what is already spelled > out in RFC[1]: > * Backports can be made to dormant support branches without requiring a > proposal or votes, subject to the "exercise good judgement" clause in the > RFC. > * Backports to multiple support branches can be made in any order as long > as eventually all gaps are filled (make sure the Fix Versions list in Jira > always accurately reflects which branches do have the fix). > > On 8/28/20, 1:10 PM, "Owen Nichols" <onich...@vmware.com> wrote: > > I noticed a recent change on support/1.12 that was not preceded by a > backport proposal. > > I re-read the Shipping Patch Releases RFC[1] which was adopted earlier > this year, and it doesn’t seem to mention anywhere that a backport proposal > is required for “dormant” support branches. > > However, it does explicitly call out “if a fix is present in release > N-2 it should also be present in N-1 and N releases.” Normally the best > way to satisfy this is to backport to support/1.13 first (which definitely > does[2] require a backport proposal as we have an active release in > progress). > > Questions for the Geode community: > > 1. Is an out-of-order backport acceptable, and if so, should there > be any upper limit on how long to tolerate the inconsistency before a > revert would be required on the older branch? The risk here is that a > 1.12.1 could ship before a 1.13.1, causing a user upgrading from 1.12.1 to > 1.13.0 to experience a regression. > 2. Should we clarify that ALL backports to support branches require > a dev list proposal and three +1’s? Or should we clarify that only > backports to an ACTIVE release branch need community approval? > > [1] https://www.cwiki.us/display/GEODE/Shipping+patch+releases > [2] > https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode#ReleasingApacheGeode-Acceptcriticalfixestothesupportbranch > >
