Hmm, I thought I had added that already. I guess I missed it. Sorry for the 
confusion, and thanks for the update.

best,
Colin


On Tue, Jul 30, 2024, at 15:06, Jun Rao wrote:
> Thanks for updating the KIP, Justine.
>
> Jun
>
> On Tue, Jul 30, 2024 at 1:37 PM Justine Olshan <jols...@confluent.io.invalid>
> wrote:
>
>> I added this update to the end of the section Colin added.
>>
>> Justine
>>
>> On Tue, Jul 30, 2024 at 11:01 AM Jun Rao <j...@confluent.io.invalid> wrote:
>>
>> > Hi, Colin,
>> >
>> > Thanks for the update. We also excluded supported features with
>> maxVersion
>> > of 0 from both ApiVersionResponse and BrokerRegistrationRequest, and
>> > excluded finalized features with version of 0 from ApiVersionResponse. It
>> > would be useful to document those too.
>> >
>> > Jun
>> >
>> > On Mon, Jul 29, 2024 at 9:25 PM Colin McCabe <cmcc...@apache.org> wrote:
>> >
>> > > Hi Jun,
>> > >
>> > > Just to close the loop on this... the KIP now mentions both
>> > > ApiVersionResponse and BrokerRegistrationRequest.
>> > >
>> > > best,
>> > > Colin
>> > >
>> > > On Mon, Jul 8, 2024, at 14:57, Jun Rao wrote:
>> > > > Hi, Colin,
>> > > >
>> > > > Thanks for the update. Since the PR also introduces a new version of
>> > > > BrokerRegistrationRequest, could we include that change in the KIP
>> > update
>> > > > too?
>> > > >
>> > > > Jun
>> > > >
>> > > > On Mon, Jul 8, 2024 at 11:08 AM Colin McCabe <cmcc...@apache.org>
>> > wrote:
>> > > >
>> > > >> Hi all,
>> > > >>
>> > > >> I've updated the approach in
>> > https://github.com/apache/kafka/pull/16421
>> > > >> so that we change the minVersion=0 to minVersion=1 in older
>> > > >> ApiVersionsResponses.
>> > > >>
>> > > >> I hope we can get this in soon and unblock the features that are
>> > waiting
>> > > >> for it!
>> > > >>
>> > > >> best,
>> > > >> Colin
>> > > >>
>> > > >> On Wed, Jul 3, 2024, at 10:55, Jun Rao wrote:
>> > > >> > Hi, David,
>> > > >> >
>> > > >> > Thanks for the reply. In the common case, there is no difference
>> > > between
>> > > >> > omitting just v0 of the feature or omitting the feature
>> completely.
>> > > It's
>> > > >> > just when an old client is used, there is some difference. To me,
>> > > >> > omitting just v0 of the feature seems slightly better for the old
>> > > client.
>> > > >> >
>> > > >> > Jun
>> > > >> >
>> > > >> > On Wed, Jul 3, 2024 at 9:45 AM David Jacot
>> > > <dja...@confluent.io.invalid>
>> > > >> > wrote:
>> > > >> >
>> > > >> >> Hi Jun, Colin,
>> > > >> >>
>> > > >> >> Thanks for your replies.
>> > > >> >>
>> > > >> >> If the FeatureCommand relies on version 0 too, my suggestion does
>> > not
>> > > >> work.
>> > > >> >> Omitting the features for old clients as suggested by Colin seems
>> > > fine
>> > > >> for
>> > > >> >> me. In practice, administrators will usually use a version of
>> > > >> >> FeatureCommand matching the cluster version so the impact is not
>> > too
>> > > bad
>> > > >> >> knowing that the first features will be introduced from 3.9 on.
>> > > >> >>
>> > > >> >> Best,
>> > > >> >> David
>> > > >> >>
>> > > >> >> On Tue, Jul 2, 2024 at 2:15 AM Colin McCabe <cmcc...@apache.org>
>> > > wrote:
>> > > >> >>
>> > > >> >> > Hi David,
>> > > >> >> >
>> > > >> >> > In the ApiVersionsResponse, we really don't have an easy way of
>> > > >> mapping
>> > > >> >> > finalizedVersion = 1 to "off" in older releases such as 3.7.0.
>> > For
>> > > >> >> example,
>> > > >> >> > if a 3.9.0 broker advertises that it has finalized
>> group.version
>> > =
>> > > 1,
>> > > >> >> that
>> > > >> >> > will be treated by 3.7.0 as a brand new feature, not as
>> "KIP-848
>> > is
>> > > >> off."
>> > > >> >> > However, I suppose we could work around this by not setting a
>> > > >> >> > finalizedVersion at all for group.version (or any other
>> feature)
>> > if
>> > > >> its
>> > > >> >> > finalized level was 1. We could also work around the "deletion
>> =
>> > > set
>> > > >> to
>> > > >> >> 0"
>> > > >> >> > issue on the server side. The server can translate requests to
>> > set
>> > > the
>> > > >> >> > finalized level to 0, into requests to set it to 1.
>> > > >> >> >
>> > > >> >> > So maybe this solution is worth considering, although it's
>> > > >> unfortunate to
>> > > >> >> > lose 0. I suppose we'd have to special case metadata.version
>> > being
>> > > >> set to
>> > > >> >> > 1, since that was NOT equivalent to it being "off"
>> > > >> >> >
>> > > >> >> > best,
>> > > >> >> > Colin
>> > > >> >> >
>> > > >> >> >
>> > > >> >> > On Mon, Jul 1, 2024, at 10:11, Jun Rao wrote:
>> > > >> >> > > Hi, David,
>> > > >> >> > >
>> > > >> >> > > Yes, that's another option. It probably has its own
>> challenges.
>> > > For
>> > > >> >> > > example, the FeatureCommand tool currently treats disabling a
>> > > >> feature
>> > > >> >> as
>> > > >> >> > > setting the version to 0. It would be useful to get Jose's
>> > > opinion
>> > > >> on
>> > > >> >> > this
>> > > >> >> > > since he introduced version 0 in the kraft.version feature.
>> > > >> >> > >
>> > > >> >> > > Thanks,
>> > > >> >> > >
>> > > >> >> > > Jun
>> > > >> >> > >
>> > > >> >> > > On Sun, Jun 30, 2024 at 11:48 PM David Jacot
>> > > >> >> <dja...@confluent.io.invalid
>> > > >> >> > >
>> > > >> >> > > wrote:
>> > > >> >> > >
>> > > >> >> > >> Hi Jun, Colin,
>> > > >> >> > >>
>> > > >> >> > >> Have we considered sticking with the range going from
>> version
>> > 1
>> > > to
>> > > >> N
>> > > >> >> > where
>> > > >> >> > >> version 1 would be the equivalent of "disabled"? In the
>> > > >> group.version
>> > > >> >> > case,
>> > > >> >> > >> we could introduce group.version=1 that does basically
>> nothing
>> > > and
>> > > >> >> > >> group.version=2 that enables the new protocol. I suppose
>> that
>> > we
>> > > >> could
>> > > >> >> > do
>> > > >> >> > >> the same for the other features. I agree that it is less
>> > elegant
>> > > >> but
>> > > >> >> it
>> > > >> >> > >> would avoid all the backward compatibility issues.
>> > > >> >> > >>
>> > > >> >> > >> Best,
>> > > >> >> > >> David
>> > > >> >> > >>
>> > > >> >> > >> On Fri, Jun 28, 2024 at 6:02 PM Jun Rao
>> > > <j...@confluent.io.invalid>
>> > > >> >> > wrote:
>> > > >> >> > >>
>> > > >> >> > >> > Hi, Colin,
>> > > >> >> > >> >
>> > > >> >> > >> > Yes, #3 is the scenario that I was thinking about.
>> > > >> >> > >> >
>> > > >> >> > >> > In either approach, there will be some information missing
>> > in
>> > > the
>> > > >> >> old
>> > > >> >> > >> > client. It seems that we should just pick the one that's
>> > less
>> > > >> wrong.
>> > > >> >> > In
>> > > >> >> > >> the
>> > > >> >> > >> > more common case when a feature is finalized on the
>> server,
>> > > >> >> > presenting a
>> > > >> >> > >> > supported feature with a range of 1-1 seems less wrong
>> than
>> > > >> omitting
>> > > >> >> > it
>> > > >> >> > >> in
>> > > >> >> > >> > the output of "kafka-features describe".
>> > > >> >> > >> >
>> > > >> >> > >> > Thanks,
>> > > >> >> > >> >
>> > > >> >> > >> > Jun
>> > > >> >> > >> >
>> > > >> >> > >> > On Thu, Jun 27, 2024 at 9:52 PM Colin McCabe <
>> > > cmcc...@apache.org
>> > > >> >
>> > > >> >> > wrote:
>> > > >> >> > >> >
>> > > >> >> > >> > > Hi Jun,
>> > > >> >> > >> > >
>> > > >> >> > >> > > This is a fair question. I think there's a few different
>> > > >> scenarios
>> > > >> >> > to
>> > > >> >> > >> > > consider:
>> > > >> >> > >> > >
>> > > >> >> > >> > > 1. mixed server software versions in a single cluster
>> > > >> >> > >> > >
>> > > >> >> > >> > > 2. new client software + old server software
>> > > >> >> > >> > >
>> > > >> >> > >> > > 3. old client software + new server software
>> > > >> >> > >> > >
>> > > >> >> > >> > > In scenario #1 and #2, we have old (pre-3.9) server
>> > > software in
>> > > >> >> the
>> > > >> >> > >> mix.
>> > > >> >> > >> > > This old software won't support features like
>> > group.version
>> > > and
>> > > >> >> > >> > > kraft.version. As we know, there are no features
>> supported
>> > > in
>> > > >> 3.8
>> > > >> >> > and
>> > > >> >> > >> > older
>> > > >> >> > >> > > except metadata.version itself. So the fact that we
>> leave
>> > > out
>> > > >> some
>> > > >> >> > >> stuff
>> > > >> >> > >> > > from the ApiVersionResponse isn't terribly significant.
>> We
>> > > >> weren't
>> > > >> >> > >> going
>> > > >> >> > >> > to
>> > > >> >> > >> > > be able to enable those post-3.8 features anyway, since
>> > > >> enabling a
>> > > >> >> > >> > feature
>> > > >> >> > >> > > requires ALL server nodes to support it.
>> > > >> >> > >> > >
>> > > >> >> > >> > > Scenario #3 is more interesting. With new server
>> software,
>> > > >> >> features
>> > > >> >> > >> like
>> > > >> >> > >> > > group.version and kraft.version may be enabled. But due
>> to
>> > > the
>> > > >> >> > >> > KAFKA-17011
>> > > >> >> > >> > > bug, we cannot accurately communicate the supported
>> > feature
>> > > >> range
>> > > >> >> > back
>> > > >> >> > >> to
>> > > >> >> > >> > > the old client.
>> > > >> >> > >> > >
>> > > >> >> > >> > > What is the impact of this? It depends on what the
>> client
>> > > is.
>> > > >> >> Today,
>> > > >> >> > >> the
>> > > >> >> > >> > > only client that cares about feature versions is admin
>> > > client,
>> > > >> >> which
>> > > >> >> > >> can
>> > > >> >> > >> > > surface them through the Admin.describeFeatures API. So
>> if
>> > > we
>> > > >> omit
>> > > >> >> > the
>> > > >> >> > >> > > supported feature range, admi client won't report it. If
>> > we
>> > > >> fudge
>> > > >> >> > it by
>> > > >> >> > >> > > reporting it as 1-1 instead of 0-1, admin client will
>> > report
>> > > >> the
>> > > >> >> > fudged
>> > > >> >> > >> > > version.
>> > > >> >> > >> > >
>> > > >> >> > >> > > In theory, there could be other clients looking at the
>> > > >> supported
>> > > >> >> > >> feature
>> > > >> >> > >> > > ranges later, but I guess those will be post-3.8, if
>> they
>> > > ever
>> > > >> >> > exist,
>> > > >> >> > >> and
>> > > >> >> > >> > > so not subject to this problem.
>> > > >> >> > >> > >
>> > > >> >> > >> > > AdminClient returns a separate map for "supported
>> > features"
>> > > and
>> > > >> >> > >> > "finalized
>> > > >> >> > >> > > features." So leaving out the supported versions for
>> > > >> group.version
>> > > >> >> > and
>> > > >> >> > >> > > kraft.version will not prevent the client from returning
>> > the
>> > > >> >> > finalized
>> > > >> >> > >> > > versions of those features to the old client.
>> > > >> >> > >> > >
>> > > >> >> > >> > > So basically we have a choice between missing
>> information
>> > in
>> > > >> >> > >> > > Admin.describeFeatures and wrong information. I would
>> lean
>> > > >> towards
>> > > >> >> > the
>> > > >> >> > >> > > missing information path, but I guess we should try out
>> an
>> > > old
>> > > >> >> > build of
>> > > >> >> > >> > > kafka-features.sh against a server with one of the new
>> > > features
>> > > >> >> > >> enabled,
>> > > >> >> > >> > to
>> > > >> >> > >> > > make sure it looks the way we want.
>> > > >> >> > >> > >
>> > > >> >> > >> > > best,
>> > > >> >> > >> > > Colin
>> > > >> >> > >> > >
>> > > >> >> > >> > >
>> > > >> >> > >> > > On Thu, Jun 27, 2024, at 14:01, Jun Rao wrote:
>> > > >> >> > >> > > > Hi, Colin,
>> > > >> >> > >> > > >
>> > > >> >> > >> > > > ApiVersionResponse includes both supported and
>> finalized
>> > > >> >> > features. If
>> > > >> >> > >> > we
>> > > >> >> > >> > > > only suppress features in the supported field, but not
>> > in
>> > > the
>> > > >> >> > >> finalized
>> > > >> >> > >> > > > field, it can potentially lead to inconsistency in the
>> > > older
>> > > >> >> > client.
>> > > >> >> > >> > For
>> > > >> >> > >> > > > example, if a future feature supporting V0 is
>> finalized
>> > in
>> > > >> the
>> > > >> >> > >> broker,
>> > > >> >> > >> > an
>> > > >> >> > >> > > > old client issuing V3 of ApiVersionRequest will see
>> the
>> > > >> feature
>> > > >> >> in
>> > > >> >> > >> the
>> > > >> >> > >> > > > finalized field, but not in the supported field.
>> > > >> >> > >> > > >
>> > > >> >> > >> > > > An alternative approach is to still include all
>> features
>> > > in
>> > > >> the
>> > > >> >> > >> > supported
>> > > >> >> > >> > > > field, but replace minVersion of 0 with 1. This may
>> > still
>> > > >> lead
>> > > >> >> to
>> > > >> >> > >> > > > inconsistency if a future feature is finalized at
>> > version
>> > > 0.
>> > > >> >> > However,
>> > > >> >> > >> > > since
>> > > >> >> > >> > > > downgrading is less frequent than upgrading, this
>> > approach
>> > > >> seems
>> > > >> >> > >> > slightly
>> > > >> >> > >> > > > more consistent.
>> > > >> >> > >> > > >
>> > > >> >> > >> > > > No matter what approach we take, it would be useful to
>> > > >> document
>> > > >> >> > this
>> > > >> >> > >> > > > inconsistency to the old client.
>> > > >> >> > >> > > >
>> > > >> >> > >> > > > Thanks,
>> > > >> >> > >> > > >
>> > > >> >> > >> > > > Jun
>> > > >> >> > >> > > >
>> > > >> >> > >> > > > On Wed, Jun 26, 2024 at 1:18 PM Jun Rao <
>> > j...@confluent.io
>> > > >
>> > > >> >> wrote:
>> > > >> >> > >> > > >
>> > > >> >> > >> > > >> Thanks for the reply, Justine and Colin. Sounds good
>> to
>> > > me.
>> > > >> >> > >> > > >>
>> > > >> >> > >> > > >> Jun
>> > > >> >> > >> > > >>
>> > > >> >> > >> > > >> On Wed, Jun 26, 2024 at 12:54 PM Colin McCabe <
>> > > >> >> > cmcc...@apache.org>
>> > > >> >> > >> > > wrote:
>> > > >> >> > >> > > >>
>> > > >> >> > >> > > >>> Hi Justine,
>> > > >> >> > >> > > >>>
>> > > >> >> > >> > > >>> Yes, that was what I was thinking.
>> > > >> >> > >> > > >>>
>> > > >> >> > >> > > >>> best,
>> > > >> >> > >> > > >>> Colin
>> > > >> >> > >> > > >>>
>> > > >> >> > >> > > >>> On Mon, Jun 24, 2024, at 11:11, Justine Olshan
>> wrote:
>> > > >> >> > >> > > >>> > My understanding is that the tools that don't rely
>> > on
>> > > >> >> > ApiVersions
>> > > >> >> > >> > > should
>> > > >> >> > >> > > >>> > still return 0s when it is the correct value. I
>> > > believe
>> > > >> >> these
>> > > >> >> > >> > > commands
>> > > >> >> > >> > > >>> do
>> > > >> >> > >> > > >>> > not require this API and thus can show 0 as
>> > versions.
>> > > >> >> > >> > > >>> >
>> > > >> >> > >> > > >>> > Likewise, when the old ApiVersionsRequest is used
>> to
>> > > >> >> describe
>> > > >> >> > >> > > features,
>> > > >> >> > >> > > >>> we
>> > > >> >> > >> > > >>> > can't return 0 versions and we won't be able to
>> see
>> > > group
>> > > >> >> > version
>> > > >> >> > >> > > set.
>> > > >> >> > >> > > >>> > However, the new api will return 0 and the group
>> > > version
>> > > >> >> > >> correctly.
>> > > >> >> > >> > > >>> >
>> > > >> >> > >> > > >>> > Let me know if this is consistent with your
>> > thoughts,
>> > > >> Colin.
>> > > >> >> > >> > > >>> >
>> > > >> >> > >> > > >>> > Justine
>> > > >> >> > >> > > >>> >
>> > > >> >> > >> > > >>> > On Mon, Jun 24, 2024 at 10:44 AM Jun Rao
>> > > >> >> > >> <j...@confluent.io.invalid
>> > > >> >> > >> > >
>> > > >> >> > >> > > >>> wrote:
>> > > >> >> > >> > > >>> >
>> > > >> >> > >> > > >>> >> Hi, Colin,
>> > > >> >> > >> > > >>> >>
>> > > >> >> > >> > > >>> >> Thanks for the update. The proposed change seems
>> > > >> reasonable
>> > > >> >> > to
>> > > >> >> > >> me.
>> > > >> >> > >> > > >>> Just one
>> > > >> >> > >> > > >>> >> clarification.
>> > > >> >> > >> > > >>> >>
>> > > >> >> > >> > > >>> >> The KIP can show version 0 of certain features
>> with
>> > > >> >> > >> > version-mapping
>> > > >> >> > >> > > >>> >> and feature-dependencies. Will that part change?
>> > For
>> > > >> >> example,
>> > > >> >> > >> will
>> > > >> >> > >> > > the
>> > > >> >> > >> > > >>> tool
>> > > >> >> > >> > > >>> >> show version 0 features with --release-version
>> 3.8
>> > or
>> > > >> do we
>> > > >> >> > >> > exclude
>> > > >> >> > >> > > >>> them.
>> > > >> >> > >> > > >>> >>
>> > > >> >> > >> > > >>> >> bin/kafka-storage.sh version-mapping
>> > > --release-version
>> > > >> >> > 3.6-IV1
>> > > >> >> > >> > > >>> >>     metadata.version=13 (3.6-IV1)
>> > > transaction.version=0
>> > > >> >> > >> > > >>> group.version=0
>> > > >> >> > >> > > >>> >>     kraft.version=0
>> > > >> >> > >> > > >>> >>
>> > > >> >> > >> > > >>> >> Jun
>> > > >> >> > >> > > >>> >>
>> > > >> >> > >> > > >>> >> On Sat, Jun 22, 2024 at 2:19 PM José Armando
>> García
>> > > >> Sancio
>> > > >> >> > >> > > >>> >> <jsan...@confluent.io.invalid> wrote:
>> > > >> >> > >> > > >>> >>
>> > > >> >> > >> > > >>> >> > Thanks for the update Colin. The changes make
>> > > sense to
>> > > >> >> me.
>> > > >> >> > >> > > >>> >> >
>> > > >> >> > >> > > >>> >> > Are you planning to update the KIP to reflect
>> > this
>> > > new
>> > > >> >> RPC
>> > > >> >> > >> > > version?
>> > > >> >> > >> > > >>> It
>> > > >> >> > >> > > >>> >> > would be good to document the semantics
>> explained
>> > > >> above
>> > > >> >> in
>> > > >> >> > the
>> > > >> >> > >> > > KIP.
>> > > >> >> > >> > > >>> >> >
>> > > >> >> > >> > > >>> >> > Thanks!
>> > > >> >> > >> > > >>> >> >
>> > > >> >> > >> > > >>> >> > On Fri, Jun 21, 2024 at 8:22 PM Justine Olshan
>> > > >> >> > >> > > >>> >> > <jols...@confluent.io.invalid> wrote:
>> > > >> >> > >> > > >>> >> > >
>> > > >> >> > >> > > >>> >> > > Ok makes sense. I will update my PR.
>> > > >> >> > >> > > >>> >> > >
>> > > >> >> > >> > > >>> >> > > On Fri, Jun 21, 2024 at 5:09 PM Colin McCabe
>> <
>> > > >> >> > >> > > cmcc...@apache.org>
>> > > >> >> > >> > > >>> >> wrote:
>> > > >> >> > >> > > >>> >> > >
>> > > >> >> > >> > > >>> >> > > > I think it's better to suppress the
>> response
>> > in
>> > > >> v3.
>> > > >> >> The
>> > > >> >> > >> > issue
>> > > >> >> > >> > > >>> with
>> > > >> >> > >> > > >>> >> > > > modifying it is that there may be scenarios
>> > > where
>> > > >> [1,
>> > > >> >> > 1]
>> > > >> >> > >> is
>> > > >> >> > >> > > the
>> > > >> >> > >> > > >>> >> actual
>> > > >> >> > >> > > >>> >> > > > supported range, and we'd want to know
>> that.
>> > > But
>> > > >> >> > leaving
>> > > >> >> > >> out
>> > > >> >> > >> > > the
>> > > >> >> > >> > > >>> >> > feature
>> > > >> >> > >> > > >>> >> > > > should be OK for older clients (it will be
>> > the
>> > > >> case
>> > > >> >> > with
>> > > >> >> > >> > > clients
>> > > >> >> > >> > > >>> old
>> > > >> >> > >> > > >>> >> > enough
>> > > >> >> > >> > > >>> >> > > > to send a v0, v1, or v2 ApiVersionsRequest
>> > > anyway)
>> > > >> >> > >> > > >>> >> > > >
>> > > >> >> > >> > > >>> >> > > > best,
>> > > >> >> > >> > > >>> >> > > > Colin
>> > > >> >> > >> > > >>> >> > > >
>> > > >> >> > >> > > >>> >> > > > On Fri, Jun 21, 2024, at 16:46, Justine
>> > Olshan
>> > > >> wrote:
>> > > >> >> > >> > > >>> >> > > > > Thanks Colin,
>> > > >> >> > >> > > >>> >> > > > >
>> > > >> >> > >> > > >>> >> > > > > This makes sense to me. Namely in the
>> case
>> > > >> where we
>> > > >> >> > >> > perhaps
>> > > >> >> > >> > > >>> don't
>> > > >> >> > >> > > >>> >> > want to
>> > > >> >> > >> > > >>> >> > > > > support version 0 anymore, we need the
>> > range
>> > > to
>> > > >> be
>> > > >> >> > able
>> > > >> >> > >> to
>> > > >> >> > >> > > not
>> > > >> >> > >> > > >>> >> > include 0.
>> > > >> >> > >> > > >>> >> > > > > (In other words, we can't assume 0 is
>> > > supported)
>> > > >> >> > >> > > >>> >> > > > > It is unfortunate that this change is a
>> bit
>> > > >> tricky,
>> > > >> >> > but
>> > > >> >> > >> I
>> > > >> >> > >> > > think
>> > > >> >> > >> > > >>> >> it's
>> > > >> >> > >> > > >>> >> > the
>> > > >> >> > >> > > >>> >> > > > > best option.
>> > > >> >> > >> > > >>> >> > > > >
>> > > >> >> > >> > > >>> >> > > > > Can you clarify
>> > > >> >> > >> > > >>> >> > > > >> The server will simply leave out the
>> > > features
>> > > >> >> whose
>> > > >> >> > >> > minimum
>> > > >> >> > >> > > >>> >> > supported
>> > > >> >> > >> > > >>> >> > > > > value is 0 for clients that send v3
>> > > >> >> > >> > > >>> >> > > > >
>> > > >> >> > >> > > >>> >> > > > > For 3.8, I planned to set the 0s in the
>> > > >> response to
>> > > >> >> > 1.
>> > > >> >> > >> Is
>> > > >> >> > >> > it
>> > > >> >> > >> > > >>> better
>> > > >> >> > >> > > >>> >> > to
>> > > >> >> > >> > > >>> >> > > > > suppress the zero version features in the
>> > > >> response
>> > > >> >> > so we
>> > > >> >> > >> > are
>> > > >> >> > >> > > >>> >> > consistent
>> > > >> >> > >> > > >>> >> > > > > between trunk and 3.8?
>> > > >> >> > >> > > >>> >> > > > >
>> > > >> >> > >> > > >>> >> > > > > Thanks,
>> > > >> >> > >> > > >>> >> > > > > Justine
>> > > >> >> > >> > > >>> >> > > > >
>> > > >> >> > >> > > >>> >> > > > > On Fri, Jun 21, 2024 at 4:34 PM Colin
>> > McCabe
>> > > <
>> > > >> >> > >> > > >>> cmcc...@apache.org>
>> > > >> >> > >> > > >>> >> > wrote:
>> > > >> >> > >> > > >>> >> > > > >
>> > > >> >> > >> > > >>> >> > > > >> Hi all,
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> It seems that there was a bug in older
>> > > >> versions of
>> > > >> >> > >> Kafka
>> > > >> >> > >> > > which
>> > > >> >> > >> > > >>> >> > caused
>> > > >> >> > >> > > >>> >> > > > >> deserialization problems when a
>> supported
>> > > >> feature
>> > > >> >> > range
>> > > >> >> > >> > > >>> included
>> > > >> >> > >> > > >>> >> 0.
>> > > >> >> > >> > > >>> >> > For
>> > > >> >> > >> > > >>> >> > > > >> example, the range for group.version of
>> > [0,
>> > > 1]
>> > > >> >> would
>> > > >> >> > >> be a
>> > > >> >> > >> > > >>> problem
>> > > >> >> > >> > > >>> >> in
>> > > >> >> > >> > > >>> >> > > > this
>> > > >> >> > >> > > >>> >> > > > >> situation.
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> This obviously makes supportedVersions
>> > kind
>> > > of
>> > > >> >> > useless.
>> > > >> >> > >> > Any
>> > > >> >> > >> > > >>> >> feature
>> > > >> >> > >> > > >>> >> > that
>> > > >> >> > >> > > >>> >> > > > >> doesn't exist today is effectively at v0
>> > > today
>> > > >> (v0
>> > > >> >> > is
>> > > >> >> > >> > > >>> equivalent
>> > > >> >> > >> > > >>> >> to
>> > > >> >> > >> > > >>> >> > > > "off").
>> > > >> >> > >> > > >>> >> > > > >> But if we can't declare that the server
>> > > >> supports
>> > > >> >> > [0, 1]
>> > > >> >> > >> > or
>> > > >> >> > >> > > >>> >> similar,
>> > > >> >> > >> > > >>> >> > we
>> > > >> >> > >> > > >>> >> > > > >> can't declare that it supports the
>> feature
>> > > >> being
>> > > >> >> > off.
>> > > >> >> > >> > > >>> Therefore,
>> > > >> >> > >> > > >>> >> no
>> > > >> >> > >> > > >>> >> > > > rolling
>> > > >> >> > >> > > >>> >> > > > >> upgrades are possible.
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> We noticed this bug during the 3.8
>> release
>> > > >> when we
>> > > >> >> > >> > noticed
>> > > >> >> > >> > > >>> >> problems
>> > > >> >> > >> > > >>> >> > in
>> > > >> >> > >> > > >>> >> > > > >> upgrade tests. As an addendum to
>> KIP-1022,
>> > > >> we're
>> > > >> >> > adding
>> > > >> >> > >> > the
>> > > >> >> > >> > > >>> >> > following
>> > > >> >> > >> > > >>> >> > > > >> solution:
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> - There will be a new v4 for
>> > > ApiVersionsRequest
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> - Clients that sent v4 will promise to
>> > > >> correctly
>> > > >> >> > handle
>> > > >> >> > >> > > ranges
>> > > >> >> > >> > > >>> >> that
>> > > >> >> > >> > > >>> >> > > > start
>> > > >> >> > >> > > >>> >> > > > >> with 0, such as [0, 1]
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> - The server will simply leave out the
>> > > features
>> > > >> >> > whose
>> > > >> >> > >> > > minimum
>> > > >> >> > >> > > >>> >> > supported
>> > > >> >> > >> > > >>> >> > > > >> value is 0 for clients that send v3
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> - ApiVersionsRequest v4 will be
>> supported
>> > > in AK
>> > > >> >> 3.9
>> > > >> >> > and
>> > > >> >> > >> > > >>> above. AK
>> > > >> >> > >> > > >>> >> > 3.8
>> > > >> >> > >> > > >>> >> > > > will
>> > > >> >> > >> > > >>> >> > > > >> ship with ApiVersionsRequest v3 just as
>> > > today.
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> thanks,
>> > > >> >> > >> > > >>> >> > > > >> Colin
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > > >> On Mon, Apr 15, 2024, at 11:01, Justine
>> > > Olshan
>> > > >> >> > wrote:
>> > > >> >> > >> > > >>> >> > > > >> > Hey folks,
>> > > >> >> > >> > > >>> >> > > > >> >
>> > > >> >> > >> > > >>> >> > > > >> > Thanks everyone! I will go ahead and
>> > call
>> > > it.
>> > > >> >> > >> > > >>> >> > > > >> > The KIP passes with the following +1
>> > > votes:
>> > > >> >> > >> > > >>> >> > > > >> >
>> > > >> >> > >> > > >>> >> > > > >> > - Andrew Schofield (non-binding)
>> > > >> >> > >> > > >>> >> > > > >> > - David Jacot (binding)
>> > > >> >> > >> > > >>> >> > > > >> > - José Armando García Sancio (binding)
>> > > >> >> > >> > > >>> >> > > > >> > - Jun Rao (binding)
>> > > >> >> > >> > > >>> >> > > > >> >
>> > > >> >> > >> > > >>> >> > > > >> > Thanks again,
>> > > >> >> > >> > > >>> >> > > > >> > Justine
>> > > >> >> > >> > > >>> >> > > > >> >
>> > > >> >> > >> > > >>> >> > > > >> > On Fri, Apr 12, 2024 at 11:16 AM Jun
>> Rao
>> > > >> >> > >> > > >>> >> <j...@confluent.io.invalid
>> > > >> >> > >> > > >>> >> > >
>> > > >> >> > >> > > >>> >> > > > >> wrote:
>> > > >> >> > >> > > >>> >> > > > >> >
>> > > >> >> > >> > > >>> >> > > > >> >> Hi, Justine,
>> > > >> >> > >> > > >>> >> > > > >> >>
>> > > >> >> > >> > > >>> >> > > > >> >> Thanks for the KIP. +1
>> > > >> >> > >> > > >>> >> > > > >> >>
>> > > >> >> > >> > > >>> >> > > > >> >> Jun
>> > > >> >> > >> > > >>> >> > > > >> >>
>> > > >> >> > >> > > >>> >> > > > >> >> On Wed, Apr 10, 2024 at 9:13 AM José
>> > > Armando
>> > > >> >> > García
>> > > >> >> > >> > > Sancio
>> > > >> >> > >> > > >>> >> > > > >> >> <jsan...@confluent.io.invalid>
>> wrote:
>> > > >> >> > >> > > >>> >> > > > >> >>
>> > > >> >> > >> > > >>> >> > > > >> >> > Hi Justine,
>> > > >> >> > >> > > >>> >> > > > >> >> >
>> > > >> >> > >> > > >>> >> > > > >> >> > +1 (binding)
>> > > >> >> > >> > > >>> >> > > > >> >> >
>> > > >> >> > >> > > >>> >> > > > >> >> > Thanks for the improvement.
>> > > >> >> > >> > > >>> >> > > > >> >> > --
>> > > >> >> > >> > > >>> >> > > > >> >> > -José
>> > > >> >> > >> > > >>> >> > > > >> >> >
>> > > >> >> > >> > > >>> >> > > > >> >>
>> > > >> >> > >> > > >>> >> > > > >>
>> > > >> >> > >> > > >>> >> > > >
>> > > >> >> > >> > > >>> >> >
>> > > >> >> > >> > > >>> >> >
>> > > >> >> > >> > > >>> >> >
>> > > >> >> > >> > > >>> >> > --
>> > > >> >> > >> > > >>> >> > -José
>> > > >> >> > >> > > >>> >> >
>> > > >> >> > >> > > >>> >>
>> > > >> >> > >> > > >>>
>> > > >> >> > >> > > >>
>> > > >> >> > >> > >
>> > > >> >> > >> >
>> > > >> >> > >>
>> > > >> >> >
>> > > >> >>
>> > > >>
>> > >
>> >
>>

Reply via email to