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