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