With regard to criteria, I think what Mick mentions where backports are only considered to be official if they are already running in production (I think ideally, 5.0 base + the backport if we're discussing 5.1), and what Francisco mentions regarding feature flags are both must-haves.
With regard to 5.0 becoming the backport branch instead of 5.1, it feels like we're a bit too far into the 5.0 release to retroactively mark it as "backports" instead of "stable." If operators have adopted 5.0 widely thinking that this is the new stable version, and this is after the fact changed, it could impact user trust, even if the backports don't actually introduce instability themselves. I would hate to be the operator that just finished their 5.0 upgrade only to find out that I really should have stayed on 4.1 or 4.0 if I wanted to stay on the stable release. On Thu, Oct 9, 2025 at 1:03 PM Francisco Guerrero <[email protected]> wrote: > Should we make it a strict requirement that all backported features > have to have the ability to be feature-flagged, and they should be > feature-flagged off by default? This will help with the stability of the > *backport* branch. > > Best, > - Francisco > > On 2025/10/09 15:59:52 Josh McKenzie wrote: > > > if we introduce bad bugs a long way into a stable branch, e.g. > 5.0.18; that's a really bad look for us and I fear will burn operators bad > enough that we will lose users over it. > > I agree with this statement. The nuance is that it wouldn't be on a > *stable* branch, it'd be on a *backport* branch. Now - if we don't think > users will understand the distinction between Stable and Backport, that's a > reasonable conversation to have for sure. Or if we think going from 5.0.X > as stable to 5.0.X as backport would be disruptive and break contract. > > > > That said, the same requirement of users to understand the distinction > would hold whether our backport branch was 5.0.X or 5.1.X. > > > > On Thu, Oct 9, 2025, at 11:48 AM, Mick wrote: > > > > > > > > > > If we have multiple private forks running large scale fleets > w/backported features, having that same code on the latest GA branch > doesn't unduly jeopardize the stability of that branch. > > > > > > > > > I don't agree with this extrapolation, and believe we have already > been burnt by it. > > > > > > Having someone run something in their production does not mean it > meets our GA standard. > > > Even fleets of clusters within one company has a homogeneous > deployment, and often a narrow bound of permitted data models. > > > > > > It certainly heaps, and can be critically unique feedback in helping > us get to GA, but it is certainly not alone universal, and that does matter > for our stable branches and the trillions of possible combinations of > configurations and data models operators can find themselves with. > > > > > > I want to repeat my earlier statement: if we introduce bad bugs a > long way into a stable branch, e.g. 5.0.18; that's a really bad look for > us and I fear will burn operators bad enough that we will lose users over > it. > > > > > > It might be more constructive at this point to go through the examples > of what folk are now running in production in down-streams and are they > initial candidates for back-porting. > > >
