...

We will rely on tagged fields (introduced in KIP-482) which allows additions and deletions of new fields without needing to bump versions. Once a version is flexible, deserializing tagged fields is straightforward as they are automatically ignored. We do not touch Key record types because keys are considered fixed and optional fields in keys do not make much sense.

We propose to require new fields added to existing Value records to always be tagged fields. We can modify SchemaGenerator to enforce this. Ideally, we should prevent version bumps for these records and there shouldn't be a need to as we can expect new fields to only be tagged fields but this may be difficult to enforceThis KIP opens the door to backward compatible changes to the record schemas through the use of tagged fields. Any future tagged fields will not require a version bump and older brokers can simply ignore the tagged fields they do not understand. Note that introducing a new non-tagged field in the future will not be backward compatible. We propose to deserialize unknown versions to the highest supported version as a safeguard and add a comment to advise against bumping in the chance that we add a tagged field and also bump the version.

Public Interfaces

...