Thanks for the reply Jeff. 2. Could we document that removing a non-tagged field is not backward compatible in the KIP?
Jun On Fri, Mar 31, 2023 at 7:17 AM Jeff Kim <jeff....@confluent.io.invalid> wrote: > Hi Jun, > > Thanks for the response. > > 1. Thanks for the catch. I updated the comment to say > "// KIP-915 bumping the version will no longer make this > record backward compatible." > > 2. Yes. Adding/removing a non-tagged field is not backward compatible. > We will not enforce this but instead let the developer know through > the comment. This pushes us to use tagged fields but gives us the > flexibility to introduce non backward compatible change. > > Best, > Jeff > > > On Thu, Mar 30, 2023 at 7:06 PM Jun Rao <j...@confluent.io.invalid> wrote: > > > Hi, Jeff, > > > > Thanks for the reply. > > > > 1. There are 3 references of "// KIP-915 do not bump the version" in > green > > in the KIP. Are those expected? > > > > 2. So, does that mean downgrade doesn't support the removal of a > non-tagged > > field? > > > > Thanks, > > > > Jun > > > > On Thu, Mar 30, 2023 at 2:57 PM Jeff Kim <jeff....@confluent.io.invalid> > > wrote: > > > > > Hi Ismael and Jun, > > > > > > Thank you for the comments. > > > > > > Ismael, > > > > > > I updated the KIP with "note: we will need commitment from > > > release managers to perform the minor releases". > > > Let me know your thoughts. > > > > > > Jun, > > > > > > 1. I am unsure where the KIP states that we will not bump the version > > > of TransactionLogValue. The KIP proposes to bump all Value > > > record types, so that statement should be removed. > > > > > > 2. Deserialization starts by iterating through the list of tagged > fields > > > then identifying ones that the schema knows about. So, even if the > > > downgraded > > > schema expects a tagged field, if it doesn't exist in the record > > > (removed in later version) then it is ignored. > > > > > > Best, > > > Jeff > > > > > > On Thu, Mar 30, 2023 at 5:16 PM Jun Rao <j...@confluent.io.invalid> > > wrote: > > > > > > > Hi, Jeff, > > > > > > > > Thanks for the KIP. A couple of comments. > > > > > > > > 1. The comment says that KIP-915 does not bump the version of > > > > TransactionLogValue.json, but the schema seems to bump the version > > from 0 > > > > to 1. > > > > > > > > 2. How do we support downgrade when a field is removed? Does it > require > > > the > > > > removed field to have a default? > > > > > > > > Thanks, > > > > > > > > Jun > > > > > > > > > > > > On Thu, Mar 30, 2023 at 6:49 AM Ismael Juma <ism...@juma.me.uk> > wrote: > > > > > > > > > Hi, > > > > > > > > > > I'm late to this conversation, but it's a bit odd to backport the > > > > flexible > > > > > versions change to "3.0.3, 3.1.3, 3.2.4, 3.3.3, and 3.4.1" unless > we > > > > intend > > > > > to release an update for each of these. So, I suggest that either > we > > > > commit > > > > > to releasing an update for each of these versions or we reduce the > > set > > > of > > > > > versions we backport the change to. > > > > > > > > > > Ismael > > > > > > > > > > On Wed, Mar 15, 2023 at 4:57 PM Jeff Kim > > <jeff....@confluent.io.invalid > > > > > > > > > wrote: > > > > > > > > > > > Hi folks, > > > > > > > > > > > > I would like to start a discussion thread for KIP-915: Next Gen > > Group > > > > > > Coordinator Downgrade Path which proposes the downgrade design > for > > > the > > > > > new > > > > > > group coordinator introduced in KIP-848 > > > > > > < > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-848%3A+The+Next+Generation+of+the+Consumer+Rebalance+Protocol > > > > > > > > > > > > > . > > > > > > > > > > > > KIP: > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-915%3A+Next+Gen+Group+Coordinator+Downgrade+Path > > > > > > > > > > > > Thanks, > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > >
