We have a 4-month major release cadence in Apache Kafka, and given that 3.1.0 is just released, a tentative estimate for 3.2.0 would be around early June.
Guozhang On Tue, Feb 8, 2022 at 8:19 AM Jonathan Albrecht <jonathan.albre...@ibm.com> wrote: > > > > No problem, glad that was more clear and thanks for considering it. I > totally > understand if this is not the type of change to put into a point release. > > I'd like to understand the release schedule a bit more. Is 3.2 probably > coming > out in May? > > Thanks, > > Jon > > "Bruno Cadonna" <cado...@apache.org> wrote on 2022-02-08 04:21:50 AM: > > > From: "Bruno Cadonna" <cado...@apache.org> > > To: dev@kafka.apache.org > > Date: 2022-02-08 04:22 AM > > Subject: [EXTERNAL] Re: Kafka <= 3.1 upgrade RocksDB to v6.27.3? > > > > Thank you Jonathan! Now I understand the situation better. > > > > I agree with Guozhang about the waiting times for 3.2.0, 3.0.1, and > 3.1.1. > > > > Obviously that does not satisfy the organizational requirements you > > mentioned. > > > > Best, > > Bruno > > > > On 07.02.22 23:24, Guozhang Wang wrote: > > > Thanks for the clarification Jonathan, I think timing wise, waiting to > get > > > 3.2.0 v.s. get 3.1.1 / 3.0.1 would not be much longer. > > > > > > On Mon, Feb 7, 2022 at 12:16 PM Jonathan Albrecht > <jonathan.albre...@ibm.com> > > > wrote: > > > > > >> > > >> > > >> > > >> Hi Bruno and Guozhang, > > >> > > >> Thanks for your thoughtful replies and I hope I can clarify. I work on > > >> a team that helps port open source software to s390x. The example I > used > > >> about users needing to be on a specific minor release is a general one > > >> that I see and not specific to kafka and usually its not due to > technical > > >> reasons. For example, sometimes organizations want to support the same > > >> version of a component across platforms and back porting support for > > >> s390x mean they can get to a supported version sooner. Maybe in > kafka's > > >> case, there are not technical reasons for that to happen but sometimes > > >> there are organizational reasons. > > >> > > >> Hope that clarifies where I'm coming from. I definitely don't have a > > >> specific technical issue that would be solved by back porting. I > > >> understand there are risks and it might not be appropriate for a > bugfix > > >> release which is why I wanted to ask first before going any further. > > >> > > >> Thanks, > > >> > > >> Jon > > >> > > >> "Bruno Cadonna" <cado...@apache.org> wrote on 2022-02-07 05:30:05 AM: > > >> > > >>> From: "Bruno Cadonna" <cado...@apache.org> > > >>> To: dev@kafka.apache.org > > >>> Date: 2022-02-07 05:30 AM > > >>> Subject: [EXTERNAL] Re: Kafka <= 3.1 upgrade RocksDB to v6.27.3? > > >>> > > >>> Hi Jonathan and Guozhang, > > >>> > > >>> I am pretty sure that upgrading RocksDB in 3.0.x and 3.1.x should not > be > > >>> an issue, since we recently upgraded it to 6.27.3 on trunk and > judging > > >>> from the compatibility report in the ticket [1] and the code the API > > >>> does not break backward-compatibility for the AK 3.x series. > > >>> > > >>> I am wondering, why users would not be willing to use the upcoming > 3.2.0 > > >>> if they are migrating or creating a Kafka Streams application on the > > >>> s390x platform. Even if we ported the upgrade to 3.1.1 and 3.0.1, > they > > >>> would need to wait until those versions are released. Additionally, > > >>> their applications need to comply with 3.x APIs and APIs should be > > >>> backward compatible in the 3.x releases. So, everything that works > with > > >>> 3.1.1 and 3.0.1 should also work with 3.2.0. Of course there could be > an > > >>> issue in 3.2.0 that will force them to use a 3.1.1 or 3.0.1, but that > > >>> would be rather an exception that we can then fix when the exception > > >>> happens. > > >>> > > >>> Jonathan, could you clarify what the motivation of using hypothetical > > >>> 3.1.1 or 3.0.1 with the RocksDB upgrade instead of 3.2.0 on a > platform > > >>> that was not supported before (i.e., 3.1.0 and 3.0.0) might be? > > >>> > > >>> In the end, it is always a risk to upgrade a library in a bugfix > release > > >>> without a critical issue that the upgrade fixes. > > >>> > > >>> > > >>> Best, > > >>> Bruno > > >>> > > >>> > > >>> [1] > > >> > https://issues.apache.org/jira/browse/KAFKA-13599 > > > >> > -- -- Guozhang
