Mostly to decouple from Cassandra release.  If there is a feature added does it have to wait for the next major release of Cassandra so others can consume?  Even if we can get to yearly releases that’s still a long wait.

For example Alex and I have been talking about proper fuzz testing, so best case is a year before 3rd parties could use.

Sent from my iPhone

On Jun 1, 2026, at 4:32 PM, Jeremiah Jordan <[email protected]> wrote:


Does it need to be a separate repo? Is there a reason not to use a folder in the current repo that becomes its own jar?  It can even be published separately if we like?

-Jeremiah

On Jun 1, 2026 at 10:00:15 AM, David Capwell <[email protected]> wrote:
Hi all,

We've discussed pulling utilities out of trunk before. I'd like to actually start.  My primary need is for test utilities so my focus is there.

This isn't just my need. Sidecar wants property/stateful tests but can't use ours without a published jar.

Proposed approach:

1. Define scope — start with property/stateful test utilities
2. Set up the repo and release independently of Cassandra
3. ...
4. Cassandra depends on the library

I'd focus on the fork first, before making Cassandra depend on it — keeps our builds simple and gives the lib room to stabilize. We can sort out the dependency question later (wait on releases, or use submodules?).

Happy to drive this if there's interest.

Sent from my iPhone

Reply via email to