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