Release 2.8.8 and 3.0.0?

[Rui Abreu <ra...@apache.org>]

Hi folks,

Just trying to understand if you are keen on performing a release for both
versions shortly

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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
<gr...@gmail.com> 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 <
> richard@zowalla.com> ha scritto:
>
> > I dont mind either way ;-)
> >
> > > Am 15.07.2026 um 15:00 schrieb Rui Abreu <ru...@gmail.com>:
> > >
> > > 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
> > >> <li...@gmail.com> 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 <ru...@gmail.com> 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
> > >>> <gr...@gmail.com> 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, <ru...@gmail.com> 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 <rz...@apache.org>
> > 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 <rz...@apache.org>
> > >>> 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
> > >>>>>>>>> <li...@gmail.com> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> Hi Rui,
> > >>>>>>>>>>
> > >>>>>>>>>> Are we moving to Java 25 in 3.x?
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks
> > >>>>>>>>>>
> > >>>>>>>>>> Julien
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Mon, 22 Jun 2026 at 14:57, Rui Abreu <rui.abreu@gmail.com
> > >>>>
> > >>>>> 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 <
> > >>> rui.abreu@gmail.com>
> > >>>>> 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 <
> > >>>>> rzo1@apache.org> 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 <
> > >>>>> rui.abreu@gmail.com> 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 <
> > >>>>> rui.abreu@gmail.com>
> > >>>>>>>>>>>>>>> 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 <
> > >>>>> richard@zowalla.com
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 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 <
> > >>>>> rabreu@apache.org
> > >>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 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/>
> >

Re: Release 2.8.8 and 3.0.0?

[Gianluca Graziadei <gr...@gmail.com>]

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 <
richard@zowalla.com> ha scritto:

> I dont mind either way ;-)
>
> > Am 15.07.2026 um 15:00 schrieb Rui Abreu <ru...@gmail.com>:
> >
> > 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
> >> <li...@gmail.com> 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 <ru...@gmail.com> 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
> >>> <gr...@gmail.com> 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, <ru...@gmail.com> 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 <rz...@apache.org>
> 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 <rz...@apache.org>
> >>> 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
> >>>>>>>>> <li...@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi Rui,
> >>>>>>>>>>
> >>>>>>>>>> Are we moving to Java 25 in 3.x?
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>> Julien
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, 22 Jun 2026 at 14:57, Rui Abreu <rui.abreu@gmail.com
> >>>>
> >>>>> 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 <
> >>> rui.abreu@gmail.com>
> >>>>> 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 <
> >>>>> rzo1@apache.org> 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 <
> >>>>> rui.abreu@gmail.com> 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 <
> >>>>> rui.abreu@gmail.com>
> >>>>>>>>>>>>>>> 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 <
> >>>>> richard@zowalla.com
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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 <
> >>>>> rabreu@apache.org
> >>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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/>
>

Re: Release 2.8.8 and 3.0.0?

[Richard Zowalla <ri...@zowalla.com>]

I dont mind either way ;-)

> Am 15.07.2026 um 15:00 schrieb Rui Abreu <ru...@gmail.com>:
> 
> 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
>> <li...@gmail.com> 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 <ru...@gmail.com> 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
>>> <gr...@gmail.com> 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, <ru...@gmail.com> 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 <rz...@apache.org> 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 <rz...@apache.org>
>>> 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
>>>>>>>>> <li...@gmail.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Rui,
>>>>>>>>>> 
>>>>>>>>>> Are we moving to Java 25 in 3.x?
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> 
>>>>>>>>>> Julien
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Mon, 22 Jun 2026 at 14:57, Rui Abreu <rui.abreu@gmail.com
>>>> 
>>>>> 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 <
>>> rui.abreu@gmail.com>
>>>>> 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 <
>>>>> rzo1@apache.org> 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 <
>>>>> rui.abreu@gmail.com> 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 <
>>>>> rui.abreu@gmail.com>
>>>>>>>>>>>>>>> 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 <
>>>>> richard@zowalla.com
>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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 <
>>>>> rabreu@apache.org
>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 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/>

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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
<li...@gmail.com> 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 <ru...@gmail.com> 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
> > <gr...@gmail.com> 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, <ru...@gmail.com> 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 <rz...@apache.org> 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 <rz...@apache.org>
> > 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
> > > > > > > > <li...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Rui,
> > > > > > > > >
> > > > > > > > > Are we moving to Java 25 in 3.x?
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > >
> > > > > > > > > Julien
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <rui.abreu@gmail.com
> > >
> > > > 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 <
> > rui.abreu@gmail.com>
> > > > 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 <
> > > > rzo1@apache.org> 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 <
> > > > rui.abreu@gmail.com> 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 <
> > > > rui.abreu@gmail.com>
> > > > > > > > > > > > > > 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 <
> > > > richard@zowalla.com
> > > > > > > > > > >
> > > > > > > > > > > > > > > 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 <
> > > > rabreu@apache.org
> > > > > > > > > > >:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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/>

Re: Release 2.8.8 and 3.0.0?

[Julien Nioche <li...@gmail.com>]

> 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 <ru...@gmail.com> 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
> <gr...@gmail.com> 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, <ru...@gmail.com> 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 <rz...@apache.org> 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 <rz...@apache.org>
> 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
> > > > > > > <li...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Rui,
> > > > > > > >
> > > > > > > > Are we moving to Java 25 in 3.x?
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > Julien
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <rui.abreu@gmail.com
> >
> > > 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 <
> rui.abreu@gmail.com>
> > > 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 <
> > > rzo1@apache.org> 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 <
> > > rui.abreu@gmail.com> 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 <
> > > rui.abreu@gmail.com>
> > > > > > > > > > > > > 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 <
> > > richard@zowalla.com
> > > > > > > > > >
> > > > > > > > > > > > > > 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 <
> > > rabreu@apache.org
> > > > > > > > > >:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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/>

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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
<gr...@gmail.com> 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, <ru...@gmail.com> 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 <rz...@apache.org> 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 <rz...@apache.org> 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
> > > > > > <li...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Rui,
> > > > > > >
> > > > > > > Are we moving to Java 25 in 3.x?
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Julien
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <ru...@gmail.com>
> > 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 <ru...@gmail.com>
> > 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 <
> > rzo1@apache.org> 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 <
> > rui.abreu@gmail.com> 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 <
> > rui.abreu@gmail.com>
> > > > > > > > > > > > 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 <
> > richard@zowalla.com
> > > > > > > > >
> > > > > > > > > > > > > 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 <
> > rabreu@apache.org
> > > > > > > > >:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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/>
> > > > > >
> > > >
> >

Re: Release 2.8.8 and 3.0.0?

[Gianluca Graziadei <gr...@gmail.com>]

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, <ru...@gmail.com> 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 <rz...@apache.org> 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 <rz...@apache.org> 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
> > > > > <li...@gmail.com> wrote:
> > > > > >
> > > > > > Hi Rui,
> > > > > >
> > > > > > Are we moving to Java 25 in 3.x?
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Julien
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <ru...@gmail.com>
> 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 <ru...@gmail.com>
> 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 <
> rzo1@apache.org> 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 <
> rui.abreu@gmail.com> 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 <
> rui.abreu@gmail.com>
> > > > > > > > > > > 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 <
> richard@zowalla.com
> > > > > > > >
> > > > > > > > > > > > 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 <
> rabreu@apache.org
> > > > > > > >:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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/>
> > > > >
> > >
>

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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 <rz...@apache.org> 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 <rz...@apache.org> 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
> > > > <li...@gmail.com> wrote:
> > > > >
> > > > > Hi Rui,
> > > > >
> > > > > Are we moving to Java 25 in 3.x?
> > > > >
> > > > > Thanks
> > > > >
> > > > > Julien
> > > > >
> > > > >
> > > > >
> > > > > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <ru...@gmail.com> 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 <ru...@gmail.com> 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 <rz...@apache.org> 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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > > > > > > > > > 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 <richard@zowalla.com
> > > > > > >
> > > > > > > > > > > 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 <rabreu@apache.org
> > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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/>
> > > >
> >

Re: Release 2.8.8 and 3.0.0?

[Richard Zowalla <rz...@apache.org>]

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 <rz...@apache.org> 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
> > > <li...@gmail.com> wrote:
> > > >
> > > > Hi Rui,
> > > >
> > > > Are we moving to Java 25 in 3.x?
> > > >
> > > > Thanks
> > > >
> > > > Julien
> > > >
> > > >
> > > >
> > > > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <ru...@gmail.com> 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 <ru...@gmail.com> 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 <rz...@apache.org> 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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > > > > > > > > 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 <richard@zowalla.com
> > > > > >
> > > > > > > > > > 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 <rabreu@apache.org
> > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > 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/>
> > >
> 

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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 <rz...@apache.org> 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
> > <li...@gmail.com> wrote:
> > >
> > > Hi Rui,
> > >
> > > Are we moving to Java 25 in 3.x?
> > >
> > > Thanks
> > >
> > > Julien
> > >
> > >
> > >
> > > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <ru...@gmail.com> 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 <ru...@gmail.com> 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 <rz...@apache.org> 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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > > > > > > > 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 <richard@zowalla.com
> > > > >
> > > > > > > > > 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 <rabreu@apache.org
> > > > >:
> > > > > > > > > > >
> > > > > > > > > > > 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/>
> >

Re: Release 2.8.8 and 3.0.0?

[Richard Zowalla <rz...@apache.org>]

+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
> <li...@gmail.com> wrote:
> >
> > Hi Rui,
> >
> > Are we moving to Java 25 in 3.x?
> >
> > Thanks
> >
> > Julien
> >
> >
> >
> > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <ru...@gmail.com> 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 <ru...@gmail.com> 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 <rz...@apache.org> 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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > > > > > > 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 <richard@zowalla.com
> > > >
> > > > > > > > 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 <rabreu@apache.org
> > > >:
> > > > > > > > > >
> > > > > > > > > > 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/>
> 

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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
<li...@gmail.com> wrote:
>
> Hi Rui,
>
> Are we moving to Java 25 in 3.x?
>
> Thanks
>
> Julien
>
>
>
> On Mon, 22 Jun 2026 at 14:57, Rui Abreu <ru...@gmail.com> 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 <ru...@gmail.com> 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 <rz...@apache.org> 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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > > > > > 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 <richard@zowalla.com
> > >
> > > > > > > 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 <rabreu@apache.org
> > >:
> > > > > > > > >
> > > > > > > > > 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/>

Re: Release 2.8.8 and 3.0.0?

[Julien Nioche <li...@gmail.com>]

Hi Rui,

Are we moving to Java 25 in 3.x?

Thanks

Julien



On Mon, 22 Jun 2026 at 14:57, Rui Abreu <ru...@gmail.com> 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 <ru...@gmail.com> 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 <rz...@apache.org> 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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > > > > 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 <richard@zowalla.com
> >
> > > > > > 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 <rabreu@apache.org
> >:
> > > > > > > >
> > > > > > > > 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/>

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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 <ru...@gmail.com> 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 <rz...@apache.org> 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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > > > 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 <ri...@zowalla.com>
> > > > > 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 <ra...@apache.org>:
> > > > > > >
> > > > > > > Hi folks,
> > > > > > >
> > > > > > > Just trying to understand if you are keen on performing a
> > > > > > > release for both
> > > > > > > versions shortly
> >

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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 <rz...@apache.org> 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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > > 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 <ri...@zowalla.com>
> > > > 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 <ra...@apache.org>:
> > > > > >
> > > > > > Hi folks,
> > > > > >
> > > > > > Just trying to understand if you are keen on performing a
> > > > > > release for both
> > > > > > versions shortly
>

Re: Release 2.8.8 and 3.0.0?

[Richard Zowalla <rz...@apache.org>]

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 <ru...@gmail.com> 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 <ru...@gmail.com>
> > 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 <ri...@zowalla.com>
> > > 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 <ra...@apache.org>:
> > > > > 
> > > > > Hi folks,
> > > > > 
> > > > > Just trying to understand if you are keen on performing a
> > > > > release for both
> > > > > versions shortly

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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 <ru...@gmail.com> 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 <ru...@gmail.com> 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 <ri...@zowalla.com> 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 <ra...@apache.org>:
> >> >
> >> > Hi folks,
> >> >
> >> > Just trying to understand if you are keen on performing a release for both
> >> > versions shortly

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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 <ru...@gmail.com> 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 <ri...@zowalla.com> 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 <ra...@apache.org>:
>> >
>> > Hi folks,
>> >
>> > Just trying to understand if you are keen on performing a release for both
>> > versions shortly

Re: Release 2.8.8 and 3.0.0?

[Rui Abreu <ru...@gmail.com>]

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 <ri...@zowalla.com> 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 <ra...@apache.org>:
> >
> > Hi folks,
> >
> > Just trying to understand if you are keen on performing a release for
> both
> > versions shortly
>

Re: Release 2.8.8 and 3.0.0?

[Richard Zowalla <ri...@zowalla.com>]

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 <ra...@apache.org>:
> 
> Hi folks,
> 
> Just trying to understand if you are keen on performing a release for both
> versions shortly