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:* 1. 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. 2. Branching model: read the draft to see what "One Branch to Rule Them All" means. 3. API Lifecycle: Is @BETA/@STABLE/@DEPRECATED enough? Do we need a @PRIVATE? 4. 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
