This has come up in CASSANDRA-16844, so wanted to bring to a wider audience.
As of this moment, 3 breaking changes have been detected in 4.1 (1 of them was merged into 4.0 as well), and how to resolve this has been talked about a lot, so felt its best to have this conversation here. We've agreed in the past that we want to maintain compatibility and that all changes will be done with compatibility in mind (see https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle), but we haven't clarified how we make the call on when to bump to next major. The Release Lifecycle states "Introducing a backward incompatibility change needs dev community approval via voting [voting open for 48 hours]." But this is under a section called "Outstanding questions beyond the scope of this document", maybe it's about time we finalize this and update this document? Thanks all! > On Jun 15, 2022, at 11:05 AM, Dinesh Joshi <djo...@apache.org> wrote: > > Better yet strive to maintain backward compatibility. There are very very few > occasions where backward compatibility breakage is warranted. > >> On Jun 15, 2022, at 10:59 AM, bened...@apache.org wrote: >> >> >> > I agree a broader consensus beyond those on the jira ticket should be >> > sought before committing the patch that bumps a new major. >> >> Broader consensus should be sought on any ticket that breaks backwards >> compatibility – even if we already have bumped major version. >> >> A major version bump should NOT be taken as carte blanche to break users, we >> should determine it for eadh case on a balance of benefit/cost. >> >> >> >> From: Mick Semb Wever <m...@apache.org> >> Date: Wednesday, 15 June 2022 at 17:44 >> To: dev@cassandra.apache.org <dev@cassandra.apache.org> >> Subject: Re: Cassandra project biweekly status update 2022-06-14 >> >> I'm going to jump off the email list to JIRA for this one - we've had a >> discussion ongoing about when we cut a Major vs. a Minor, what qualifies as >> an API, etc on CASSANDRA-16844 >> (https://issues.apache.org/jira/browse/CASSANDRA-16844 >> <https://issues.apache.org/jira/browse/CASSANDRA-16844>). Expect something >> to formally hit the dev mailing list about this soon, but until then we can >> keep going on the JIRA ticket. >> >> >> I need to take some blame here, for leading people down a bit of a garden >> path. >> >> The idea was that trunk is by default the next minor, and that when a patch >> lands that warrants a bump to the next major then the patch includes that >> change to build.xml's base.version. >> >> The devil is in the detail here, and it becomes a lot more clearer when >> reading CASSANDRA-16844. I'm appreciative when we can tackle these things >> in a lazy manner as they arise as real examples often bring that extra >> clarity. >> >> I agree a broader consensus beyond those on the jira ticket should be sought >> before committing the patch that bumps a new major. The broader audience may >> also help propose better solutions that don't require a major change (as was >> done in 16844), and help coordinate with other tickets also warranting a new >> major…
