Gianluca, @Richard Zowalla can we get some votes on getting 3.0.0 RC1 and 2.8.9 RC1 out?
On Sun, 12 Jul 2026 at 11:55, Julien Nioche <[email protected]> wrote: > > > I propose we release 2.8.9 with 3.0.0 and warn the community that 2.x > is EOL and that it's the last release. 2.8.9 contains a few > dependabots upgrades compared to 2.8.8, so it's worth doing. > > + 1 from me. > > Julien > > On Sat, 11 Jul 2026 at 21:26, Rui Abreu <[email protected]> wrote: > > > Note: we recently released 2.8.8 so the title of this email chain is > > wrong. It should read 2..8.9. > > > > While keeping 2.x alive for some time is appealing, the jump from > > Storm 2 to 3 is much less complex than the one made from Storm 2 to 3. > > Even with master (Storm 3) shipped with Java 25 > > We should focus our attention and resources on 3.x, which has quite a > > few interesting new additions. > > I propose we release 2.8.9 with 3.0.0 and warn the community that 2.x > > is EOL and that it's the last release. 2.8.9 contains a few > > dependabots upgrades compared to 2.8.8, so it's worth doing. > > > > On Wed, 8 Jul 2026 at 21:48, Gianluca Graziadei > > <[email protected]> wrote: > > > > > > I agree that setting an EOL for 2.X is a natural next step for the > > > project, and options b1 or b2 seem like the best approach. > > > > > > Cheers, > > > Gianluca > > > > > > > > > On Wed, 8 Jul 2026, 10:04 Rui Abreu, <[email protected]> wrote: > > > > > > > I agree @Richard Zowalla .The sooner the better, to let the community > > > > manage expectations > > > > > > > > Do you want me to set up the vote? > > > > > > > > On Wed, 8 Jul 2026 at 07:48, Richard Zowalla <[email protected]> wrote: > > > > > > > > > > Yes. We should open a discussion / vote with different options for > > > > EOLing 2.x (since resources to maintain 2.x branches and getting the > > votes > > > > needed for a release are quite sparse). > > > > > > > > > > Think primary questions for that would be: > > > > > > > > > > (a) Do we have consensus that such an EOL announcement is long > > overdue > > > > and should be put out rather soonish? > > > > > (b) Time of the announcement: Options that I see: > > > > > - b1: Directly with the projected release of the 3.0.0 marking it as > > the > > > > last release ever to be expected for OpenNLP 2.x > > > > > - b2: Shortly after - with a grace period - for instance End of Year > > > > 2026, or similar short ranged targets. > > > > > - b3: Mid of year 2027 > > > > > > > > > > Gruß > > > > > Richard > > > > > > > > > > On 2026/07/07 22:44:52 Rui Abreu wrote: > > > > > > Created this PR https://github.com/apache/storm/pull/8893 to set > > the > > > > > > baseline as Java 25. > > > > > > Additionally, we should vote on setting Apache Storm 2.x as EOL > > (it is > > > > > > only receiving dependabot updates at this point) > > > > > > > > > > > > Thank you > > > > > > > > > > > > On Mon, 29 Jun 2026 at 14:34, Richard Zowalla <[email protected]> > > wrote: > > > > > > > > > > > > > > +1 on thinking about Java 25 for 3.0.0 rather than just bumping > > to > > > > 21. > > > > > > > > > > > > > > The reason it is worth it now is the pinning fix: JEP 491 > > > > ("Synchronize Virtual Threads without Pinning"), delivered in Java 24 > > and > > > > carried into the 25 LTS. Before that, in 21 to 23, a virtual thread > > that > > > > blocked on I/O inside a synchronized block stayed pinned to its carrier > > > > thread, and under load that could exhaust the carrier pool and stall > > > > progress. That is a real concern for us, because we have a fair amount > > of > > > > synchronized code sitting in exactly the I/O bound paths where you > > would > > > > want to use VTs. On 24/25 the VT unmounts and frees the carrier while > > it > > > > waits, so we would not have to go and rewrite every synchronized block > > as > > > > ReentrantLock first, which is the migration a lot of libraries had to > > do > > > > (MySQL Connector/J, Resilience4j and others). Native/JNI is the one > > > > remaining pinning case, but that is narrow. > > > > > > > > > > > > > > Where this could actually matter in Storm: the places that spend > > > > their time waiting rather than computing are the obvious candidates. > > > > Netty/transport worker connections, external lookups in bolts (DB, > > HTTP, > > > > cache), and the various ack/metrics/heartbeat paths that talk to > > > > ZooKeeper/Nimbus. These are classic thread-per-connection or > > bounded-pool > > > > setups today, and a thread-per-task VT model could simplify them and > > scale > > > > better when a topology fans out to a lot of blocking calls > > > > > > > . > > > > > > > What we would want to be careful about: the hot path is the > > > > executor's disruptor queues and the spout/bolt processing loop, and a > > lot > > > > of that is CPU bound message passing, not blocking I/O, so VTs do not > > help > > > > there and should not be forced in. This is about targeted use in the > > I/O > > > > bound corners, not running everything on virtual threads. We would also > > > > want to watch ThreadLocal usage, since Scoped Values (finalised in 25) > > are > > > > the intended replacement and we lean on thread locals in a few spots. > > > > > > > > > > > > > > So my argument is: if we are doing a new major anyway, baselining > > > > 3.0.0 on Java 25 rather than 21 costs us little extra now and saves a > > > > second baseline bump later. It also keeps the door open to actually > > explore > > > > VTs in the blocking paths. > > > > > > > > > > > > > > Realistically it will be a good while before we are in a > > position to > > > > do a Storm 4, so 3.x is where any of this experimentation has to live > > > > regardless, and I would rather not start that line on a baseline we > > already > > > > know we will want to move off. > > > > > > > > > > > > > > I am not saying we commit to adopting VTs in 3.0.0 itself. Just > > that > > > > 25 as the baseline is the enabler, and we can prototype on a branch > > from > > > > there. > > > > > > > > > > > > > > Gruß > > > > > > > Richard > > > > > > > > > > > > > > On 2026/06/24 13:24:26 Rui Abreu wrote: > > > > > > > > Julien, master is being compiled with JDK 21, but our test > > > > pipelines > > > > > > > > run both 21 and 25. > > > > > > > > > > > > > > > > On Wed, 24 Jun 2026 at 10:49, Julien Nioche > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > Hi Rui, > > > > > > > > > > > > > > > > > > Are we moving to Java 25 in 3.x? > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <[email protected] > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hey folks, > > > > > > > > > > > > > > > > > > > > We have several good contributions in master and a few more > > > > undergoing PRs. > > > > > > > > > > I'm keen on releasing 3.0.0 to the community soon. I don't > > > > mind at all > > > > > > > > > > doing the release. > > > > > > > > > > > > > > > > > > > > Let me know what you think > > > > > > > > > > > > > > > > > > > > On Wed, 20 May 2026 at 19:02, Rui Abreu < > > [email protected]> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Totally agree. I would say we should keep merging > > dependabot > > > > PRs into > > > > > > > > > > > 2.x for some months, but only do a release if we have > > > > reports of a > > > > > > > > > > > bug, like the one we patched in 2.8.8. > > > > > > > > > > > Otherwise, 3.0.0 will be the way to go to better utilise > > our > > > > manpower > > > > > > > > > > resources. > > > > > > > > > > > > > > > > > > > > > > On Wed, 20 May 2026 at 18:38, Richard Zowalla < > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Given our current man power it might be beneficial, if > > we > > > > decide on a > > > > > > > > > > > > EOL strategy for the 2.x release line before going into > > > > 3.x (dropped > > > > > > > > > > > > clojure, Java 21 baseline), so we have a clear way on > > how > > > > long we want > > > > > > > > > > > > to support the 2.x branch with releases. > > > > > > > > > > > > > > > > > > > > > > > > Given our slow pace in getting the required votes, we > > > > might have an > > > > > > > > > > > > issue with maintaing to release lines in parallel over > > a > > > > longer period > > > > > > > > > > > > of time. Think we can do that for a few months but not > > > > endlessly. > > > > > > > > > > > > > > > > > > > > > > > > Might be worth a discussion thread on the dev@ list. > > wdyt? > > > > > > > > > > > > > > > > > > > > > > > > Am Mittwoch, dem 20.05.2026 um 16:44 +0100 schrieb Rui > > > > Abreu: > > > > > > > > > > > > > Hello @Richard Zowalla > > > > > > > > > > > > > > > > > > > > > > > > > > We can consider releasing 3.0.0 over the next week > > or so. > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 10 May 2026 at 23:09, Rui Abreu < > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the PRs @Richard Zowalla , much > > appreciated. > > > > > > > > > > > > > > I have merged them and dealt with the subsequent > > > > dependabot > > > > > > > > > > > > > > avalanche. > > > > > > > > > > > > > > Apologies if you received a whole bunch of Jenkins > > > > errors. > > > > > > > > > > > > > > I was using AI + GH client to deal with the > > dependabot > > > > PRs in > > > > > > > > > > > > > > batches > > > > > > > > > > > > > > and it was being quite helpful, right up until the > > > > point and it > > > > > > > > > > > > > > decided to merge a few PRs whose tests were still > > > > ongoing > > > > > > > > > > > > > > > > > > > > > > > > > > > > problematic Merges > > > > > > > > > > > > > > * #8632 (Jersey 4.0.2 upgrade on 2.x) > > > > > > > > > > > > > > * #8615 (Checkstyle 13.4.2 on master) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Both have been reverted and both master and 2.x > > are ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll create a RC for 2.8.8 during the week. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 10 May 2026 at 17:01, Rui Abreu < > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok, we can hold off on 3.0.0 for now. > > > > > > > > > > > > > > > I'll focus on making sure 2.8.8 has the necessary > > > > changeset and > > > > > > > > > > > > > > > then we can get the RC going. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, May 10, 2026, 16:58 Richard Zowalla < > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.8.8 is fine for me. Guess we need to > > confirmed > > > > dependabot for > > > > > > > > > > > > > > > > 2.x branches too (+ license update action) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3.0.0 would need the Java 21 bump before (as > > > > discussed in the > > > > > > > > > > > > > > > > related discussion - dont know if there are > > other > > > > things like > > > > > > > > > > > > > > > > the Jitter RFC stuff for it) - perhaps there is > > > > something else. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gruß > > > > > > > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 10.05.2026 um 17:13 schrieb Rui Abreu < > > > > [email protected] > > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi folks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Just trying to understand if you are keen on > > > > performing a > > > > > > > > > > > > > > > > > release for both > > > > > > > > > > > > > > > > > versions shortly > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > *Julien Nioche * > > > > > > > > > > > > > > > > > > > > > > > > > > > digitalpebble.com <http://www.digitalpebble.com/> > > > > > > > > > > > > > > > > > > > > > > > -- > *Julien Nioche * > > > digitalpebble.com <http://www.digitalpebble.com/>
