...

• unit and integration tests for StreamPartitionsAssigner that must react correctly to configs and received subscription versions
• system tests that perform rolling bounce upgrades as described above
  • this should include failure scenario during the upgrade
  • this should include "simulated upgrades" to metadata version 4, to ensure that the implemented "version probing" work correct for future changes

Test matrix:

 (*): requires back porting of KAFKA-6054 to older branches

Rejected Alternatives

• use consumer's built-in protocal upgrade mechanism (ie, register multple "assigment strategies")
  • has the disadvantage that we need to implement two StreamsPartitionAssingor classes
  • increased network traffic during rebalance
  • encoding "supported version" in metadata (ie, version probing) subsumes this approach for future releases
  • if we want to "disable" the old protocol, a second rebalance is required, too
• Don't fix KAFKA-6054
  • it's a simple fix to include: just add one more accepted values to parameter upgrade.from
  • it's s fair question, how many people will run with Streams 0.10.0 – note thought, that if people are "stuck" with 0.10.0 broker, they cannot use 0.10.1 or newer as it's not backwards compatible to 0.10.0 – thus, might be more than expected
• Fix KAFKA-6054 only for 1.2 release
  • it's a relatively simply fix for older releases (main design work is already covered and writing the code is not too complex)
  • it's unclear though if we will have bug-fix releases for older versions; thus nobody might ever be able to get this code (if they don't build from corresponding dev-branches themselves)

...