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. >
+1 to always, by default, maintaining compatibility. Note, a major bump isn't only about compatibility breakages per se, but a) time to clean up deprecated code, and b) delineating upgrade paths. > 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? > IIRC, though i can easily be wrong, this was meant for breaking changes within a major, e.g. after a beta release. Not that the same formality cannot also be applied to trunk dev, as it ensures a desired visibility, though I wonder if we will solve it in practice most of the time with the preceding [DISCUSS] thread. We also have the discussion wrt what are breaking changes. Are we intending to evolve what interfaces and behaviour we provide, and to what degree, compatibility over via these discussions/votes?
