> 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. Strong +1 from me here. Having guidance for people working on the codebase to understand what is and isn't considered a public API will help inform how we shape these things and keep things stable for our userbase.
On Sun, Jun 26, 2022, at 12:58 PM, Ekaterina Dimitrova wrote: > “+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?
