Yeah, my position is this isn’t a problem. The full range of upgrade tests only need to be run at most on release, and we’re not talking about supporting loads of versions. I think it’s fine to (as before) expect people upgrade from and to the highest patch version of any minor release, so the multiplicity of paths is pretty tractable.
I anyway don’t really see how this is relevant to the 6.0 vs 5.1 topic, 5.1 has the exact same issue to grapple with. Supported upgrade paths is its own discussion, and it should consider only how painful it is for us as a community to support a given option. I continue to struggle to see why you want to argue it’s a problem for users to have more options. Anyone who thinks you need to upgrade between adjacent major versions loses *nothing* by us expanding the supported upgrade paths. It’s still true that this is safe. > On 28 Jan 2025, at 02:24, Jordan West <jw...@apache.org> wrote: > > Mick, > > There is a lot to respond to here and I think we might need a few other > threads to avoid a spidering conversation but I wanted to respond to what I > saw is at least part of the crux of your concern: our recommended upgrade > paths. To take a snippet from your email "A little empathy for our users goes > a long way." While I agree clarity is important, forcing our users to > upgrade multiple times is not in their best interest. Several threads > recently have touched on why. Forcing more upgrades on users asks them to > take more risk. I think a lot of what you laid out makes the world of > upgrades similar for us Cassandra committers but not Cassandra operators > (whether they have 1 cluster or 10,000). > > That said, so does asking them to try upgrades we don't test. If we are going > to support more than "next major version" upgrades, we must test it. I don't > think there is a strong debate on that. I don't know how to solve the testing > resources problem besides to try and "fundraise" (as you suggest) for more > (companies that for example find the desire to skip a major important could > consider contributing resources to test it, although these days I recognize > resources for this could be slim, and I admit I wouldn't know where to start > myself, basically I don't want to trivialize it). At the same time, doesn't > less testing resources primarily translate to longer test runs? Upgrade tests > don't need to be run on every commit. When I worked on Riak we had very > comprehensive upgrade testing (pretty much the full matrix of versions) and > we had a schedule we ran these tests on ahead of release. Could you share > some more details on the resource issues and their impacts? > > Jordan
