Hi all, I think we have lazy consensus here, so we can move on with the plan as proposed.
Gruß Richard On 2026/03/30 17:52:21 Richard Zowalla wrote: > Hi all, > > Thanks for the feedback so far. Are there any further comments or objections? > > If not, I’ll assume lazy consensus after ~72 hours. > > Gruß > > Richard > > > > Am 28.03.2026 um 10:34 schrieb Richard Zowalla <[email protected]>: > > > > Hi everyone, > > > > As we all know, Storm is effectively in maintenance mode with only a > > handful of active committers keeping the lights on. That's not a criticism, > > it's the reality. > > > > But it means we should be deliberate about reducing complexity wherever we > > can, so the people who are here can focus on what matters: keeping Storm > > stable, secure, and usable. > > > > With that in mind, I'd like to propose a Storm 3.0.0 major release with two > > key changes: > > > > 1) Remove the Clojure dependency entirel > > 2) Move the minimum Java baseline to Java 21 > > > > > > 1. Removing Clojure > > > > Storm's core was rewritten in Java years ago, but we still carry ~5,000 > > lines of Clojure integration tests, plus supporting modules and build > > tooling: storm-clojure, storm-clojure-test, the custom Maven shade > > transformer, clojure-maven-plugin, and transitive dependencies like Clojure > > 1.12.x, carbonite, tools.logging, which would need adjustments / updates > > for Maven 4. > > > > The practical problem: nobody on the current committer roster maintains > > Clojure fluency at the level needed to confidently review or evolve these > > tests. > > They've become frozen artifacts, i.e. we work around them rather than with > > them. For a small maintainer team, carrying an entire second language > > ecosystem that nobody actively speaks is exactly the kind of complexity we > > should shed. > > > > Meanwhile our Java test infrastructure is already mature. Work is already > > underway to port these tests to Java. > > > > A major version bump is the right moment to drop a language dependency > > cleanly. It simplifies the build, lowers the barrier for any new > > contributors, and removes tooling that nobody is actively maintaining. > > > > > > 2. Java 21 baseline > > > > A major version bump is always a possibility to raise the Java baseline. > > Moving our baseline from Java 17 to 21 lets us adopt virtual threads, > > pattern matching, record patterns, sealed classes, and the foreign function > > API: all of which can simplify Storm internals going forward. > > For a small team, being able to write less code for the same result is a > > real benefit. Most downstream users on current JDK LTS tracks are already > > on 21. > > > > 3. This is a discuss thread, not a vote. Questions for the list: > > > > - Are there objections to dropping Clojure in a 3.0.0? > > - Is Java 21 the right baseline, or should we even consider 25? > > - Any other changes that should ride along in a major bump? > > - Timeline preferences? > > > > Looking forward to the discussion. > > > > Gruß > > Richard > >
