> I don’t think it has to be all that complicated? Definitely not. We've just never documented it afaict.
On Tue, Jun 28, 2022, at 2:58 PM, Benedict wrote: > > 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? >>
