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