...

• Detect if the grouping key has changed or not.
• If the grouping key has not changed, send only a single event containing both the oldValue and the newValue to the downstream node.
• If the grouping key has changed, continue with the old behavior i.e. send two events, one for the oldKey with the oldValue, and one for the newKey with the newValue.

It is not necessary to review this as part of the KIP process but for those who are interested, here is an early pull request with the proposed changes.

Public Interfaces

KGroupedTable interface 

...

1. The first rolling bounce is to set the config upgrade.from="older version we are rolling back to"  and then bounce each instance.
   
   It's important to wait in this state for a few minutes and make sure that the application has finished processing any "in-flight" messages (i.e. those written into any repartition topics) which will have been written in the new serialization format. Once we revert back to the previous version of the byte code in the next step, Kafka Streams will no longer know how to deserialize messages in the new serialization format and will throw an exception. 
2. The second rolling bounce is to replace the byte code (i.e. swap the jars), remove the `upgrade.from` config, and bounce each instance.

Test Plan

The change will be covered with unit tests.

Rejected Alternatives

Do nothing i.e. preserve the current state of affairs.

Draft Pull Request

It is not necessary to review this as part of the KIP process but for those who are interested, this pull request demonstrates one way of implementing the proposed changes.