Josh and I talked about this offline and not perfectly in-sync so would be good to get other peoples views
My take is that if you are adding the API to this shared repo we need to care about backwards compatibility so things should be PUBLIC by default (anything that is java public is part of the public interface and breaking changes are not allowed without a long enough deprecation window similar to Cassandra’s.). I think Josh is in favor of using a annotation to mark that a API is public, but without custom tooling I don’t think anyone will notice and then we will get to a effectively public state and breaking changes will be a nightmare to deal with for the community. So if you want to post the API here, it should be stable and we shouldn’t be putting APIs that have not been fleshed out first. > On Aug 7, 2026, at 8:16 AM, Josh McKenzie <[email protected]> wrote: > > One thing worth immediately calling out that we might want to split out: we > could do this work in Ant. > > It would be somewhat more imperative and brittle: we'd explicitly orchestrate > the build ordering in Ant, while relying on the Gradle build inside Accord > for its cassandra-utils dependency resolution / source substitution. That > leaves us with a somewhat more complicated mixed Ant/Gradle build > relationship but it's entirely workable for an interim time. > > So if the Gradle migration is a sticking point, we can break that out into a > separate discussion and CEP rather than making it part of CEP-65. > > Doing so would mean retaining and extending some of the complexity in our > existing build system that a future migration could remove, but it's not a > crushing amount of additional complexity. The benefit of doing that work here > with this CEP is that we have one more concrete build need providing a reason > to move toward a unified build stack, and it fits the "clean things up and > refactor as you're working on things that could benefit from that work" > approach many have argued for in the past on the project. > > On Fri, Aug 7, 2026, at 10:58 AM, Josh McKenzie wrote: >> As per the previous ML thread: [DISCUSS] Forking Cassandra utilities into a >> separately released library >> <https://lists.apache.org/thread/7kllp45vvonsg7ggzxpz39c5kdcy7r6g>, David >> and I put together a draft of what we discussed and worked through some >> implications and requirements that came up as we tried to nail things down. >> >> The goal here is to provide a material backstop to continue our discussion >> and version it. As with all CEP DISCUSS threads, this is very fluid and none >> of it should be taken as settled or an implicit mandate. Let's see if we can >> make some progress on this long-standing pain point in our ecosystem. >> >> CEP-65 DRAFT: link >> <https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/446071230/CEP-65+cassandra-utils+-+A+shared+utility+library+for+the+cassandra+ecosystem+DRAFT> >> >> Why You Should Read This Draft: >> Build system impact: we need a parent project and one of its submodule to >> depend on another submodule. We're proposing freezing ant's API surface >> area, maintaining that into perpetuity, and moving to gradle going forward. >> Branching model: read the draft to see what "One Branch to Rule Them All" >> means. >> API Lifecycle: Is @BETA/@STABLE/@DEPRECATED enough? Do we need a @PRIVATE? >> To Release or Not To Release: we're proposing consumers embed this as a >> submodule initially to minimize friction in moving shared code into a shared >> space. >> We have 1 outstanding unanswered question we didn't come up with an >> opinionated proposal for: >> >> What should unannotated methods and classes in the library be considered by >> potential consumers? @PRIVATE? @PUBLIC? Should we lint and fail on any class >> without a top-level annotation forcing us to make a choice on our dev list >> [DISCUSS] threads whenever we bring in new things? >> >> There's no timeline on this thread; let's keep turning the crank on this >> until we've hit our pareto-polish frontier. ;) >> >> ~Josh >> >> >
