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
