I don’t think it has to be all that complicated? If it’s a part of our UX it’s probably something we should maintain backwards compatibility for.
If it’s part of our internal codebase, probably not. The only two “public” APIs we have inside the codebase that I’m aware of are triggers and secondary indexes, and these are provided with limited warranty and an expectation of technical sophistication for their users. I think there has always been an expectation that users of these features will bear the cost of migration to any new API versions we might introduce between majors. > On 28 Jun 2022, at 19:39, Josh McKenzie <jmcken...@apache.org> wrote: > > >> >> 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? >
