Thanks, Kim. The KIP looks good to me now. Jun
On Fri, Mar 31, 2023 at 10:00 AM Jeff Kim <jeff....@confluent.io.invalid> wrote: > Hi Jun, > > Thanks for the comment. I have updated the statement: > "Note that introducing a new non-tagged field or removing an > existing non-tagged field in the future will not be backward compatible." > > Best, > Jeff > > On Fri, Mar 31, 2023 at 12:57 PM Jun Rao <j...@confluent.io.invalid> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
