I dont mind either way ;-)

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

Reply via email to