Re: [DISCUSS] Shipping patch releases

[Alexander Murmann <am...@apache.org>]

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 <on...@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" <on...@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
>
>