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
> >>
