Thanks for the input. However, I am wondering if releasing 3.9 makes
sense if KIP-1012 won't make it?
My understanding was we do 3.9 only to not delay 3.8 and not delay 4.0.
If we would go with a 3.10, would it also be an "intermediate" release
like 3.9? Or would it replace 4.0? For the first case, why not just
delay 3.9 until everything is ready? And for the latest case, why not
just do the 3.9 release in Nov and drop an intermediate release all
together?
What do we gain by a 3.10 release?
-Matthias
On 7/30/24 10:26 AM, Josep Prat wrote:
+1 Greg. I'd be really happy to bump trunk to 4.0.0, but only once we know
we can safely do so.
On Tue, Jul 30, 2024 at 7:24 PM Greg Harris <greg.har...@aiven.io.invalid>
wrote:
Hi all,
I agree that we are not yet ready for breaking changes on trunk, so I
opened a PR to bump to 3.10.0-SNAPSHOT:
https://github.com/apache/kafka/pull/16732
When KIP-853 is feature complete, we can bump to 4.0.0-SNAPSHOT.
Thanks,
Greg
On Tue, Jul 30, 2024 at 10:01 AM Josep Prat <josep.p...@aiven.io.invalid>
wrote:
Hi all,
As per KIP-1012[1] we can't yet say if the next release will be 3.10.0 or
4.0.0. It will come down to the state of KIP-853 in 3.9.0.
So, in my opinion we should still wait before committing breaking changes
on trunk until we know for sure that KIP-853 will make it.
Maybe Jose can share more about the chances of this.
[1]
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1012%3A+The+need+for+a+Kafka+3.8.x+release
Best
------------------
Josep Prat
Open Source Engineering Director, Aiven
josep.p...@aiven.io | +491715557497 | aiven.io
Aiven Deutschland GmbH
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen,
Anna Richardson, Kenneth Chen
Amtsgericht Charlottenburg, HRB 209739 B
On Tue, Jul 30, 2024, 18:52 Matthias J. Sax <mj...@apache.org> wrote:
Thanks for cutting the release branch.
It's great to see `trunk` being bumped to 4.0-SNAPSHOT, and I wanted to
follow up on this:
We have a bunch of tickets that we can only ship with 4.0 release, and
these tickets were blocked so far. I wanted to get confirmation that we
will stick with 4.0 coming after 3.9, and that we can start to work on
these tickets? Or is there any reason why we should still hold off to
pick them up? We don't want to delay them unnecessary to make sure we
can them all into 4.0 release, but of course also don't want to work on
them prematurely (to avoid that we have to revert them after merging).
-Matthias
On 7/30/24 9:07 AM, Chia-Ping Tsai wrote:
hi Colin,
Could you please consider adding
https://issues.apache.org/jira/browse/KAFKA-16666 to 3.9.0
The issue is used to deprecate the formatters in core module. Also,
it
implements the replacements for them.
In order to follow the deprecation rules, it would be nice to have
KAFKA-16666 in 3.9.0
If you agree to have them in 3.9.0, I will cherry-pick them into
3.9.0
when
they get merged to trunk.
Best,
Chia-Ping
José Armando García Sancio <jsan...@confluent.io.invalid> 於
2024年7月30日
週二
下午11:59寫道：
Thanks Colin.
For KIP-853 (KRaft Controller Membership Changes), we still have the
following features that are in progress.
1. UpdateVoter RPC and request handling
<https://issues.apache.org/jira/browse/KAFKA-16533>
2. Storage tool changes for KIP-853
<https://issues.apache.org/jira/browse/KAFKA-16518>
3. kafka-metadata-quorum describe changes for KIP-853
<https://issues.apache.org/jira/browse/KAFKA-16521>
4. kafka-metadata-quorum add voter and remove voter changes
<https://issues.apache.org/jira/browse/KAFKA-16523>
5. Sending UpdateVoter request and response handling
<https://issues.apache.org/jira/browse/KAFKA-16534>
Can we cherry pick them to the release branch 3.9.0 when they get
merged to
trunk? They have a small impact as they shouldn't affect the rest of
Kafka
and only affect the kraft controller membership change feature. I
expected
them to get merged to the trunk branch in the coming days.
Thanks,
On Mon, Jul 29, 2024 at 7:02 PM Colin McCabe <cmcc...@apache.org>
wrote:
Hi Kafka developers and friends,
As promised, we now have a release branch for the upcoming 3.9.0
release.
Trunk has been bumped to 4.0.0-SNAPSHOT.
I'll be going over the JIRAs to move every non-blocker from this
release
to
the next release.
From this point, most changes should go to trunk.
*Blockers (existing and new that we discover while testing the
release)
will be double-committed. *Please discuss with your reviewer
whether
your
PR should go to trunk or to trunk+release so they can merge
accordingly.
*Please help us test the release! *
best,
Colin
--
-José
