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