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