“+1 to always, by default, maintaining compatibility.” +1 “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?”
While I do agree we cannot really have a fully exhaustive list, I think it is good to document further things and keep on doing it in time when discussions happen. I can see this being a benefit both for users and Cassandra developers. On Thu, 16 Jun 2022 at 18:25, Mick Semb Wever <m...@apache.org> wrote: > > > 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? >
