That has been merged into master, so it will be included. I will try to get both RC out in the coming days.
On Wed, 15 Jul 2026 at 19:15, Gianluca Graziadei <[email protected]> wrote: > > Yes, it works for me! > By the way, what do you think about merging/completing the review for this > PR before the branch cut for RC1? https://github.com/apache/storm/pull/8819 > Let me know if you think it's ready and safe to include. > > Thanks! > - Gianluca > > Il giorno mer 15 lug 2026 alle ore 15:26 Richard Zowalla < > [email protected]> ha scritto: > > > I dont mind either way ;-) > > > > > Am 15.07.2026 um 15:00 schrieb Rui Abreu <[email protected]>: > > > > > > 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/> > >
