...

kafka-configs.sh

1. Adding new options --disableenable-incremental , which is used for new client to connect to older new servers before after 2.3.0 when updating broker configs. 

Proposed Changes

1. --disableenable-incremental is only makes sense when used together with (--alter) and (--broker <broker-id>)/(--entity-types brokers), or it will be ignored.
2. --disableenable-incremental is only makes sense when used together with (--bootstrap-server)/(bootstrap-controller), we are leaving zookeeper case unchanged.
3. use AdminClient.incrementalAlterConfigs without if --disableenable-incremental flag is specified when alter broker configs, which will fail if the broker is before 2.3.0.
4. -enable-incremental is deprecated and will be removed in the future together with AdminClient.alterConfigs, and  AdminClient.incrementalAlterConfigs will be the only choice 

here is an example of changing the broker configs twice:

1. set log.cleaner.threads=2
2. set background.threads=1

in old case, version, or in the new version without --enable-incremental,  here are what happened:

1. Use kafka-configs.sh to set log.cleaner.threads=2, the client will fetch all broker configs and get a empty properties {}, merge it with the delta and get {log.cleaner.threads=2}, send it to server using AdminClient.alterConfigs(), the server will persist it to metadata storage.
2. Use kafka-configs.sh to set background.threads=1, the client will fetch all broker configs and get {log.cleaner.threads=2}, merge it with the delta and get {log.cleaner.threads=2, background.threads=1 }, send it to server using AdminClient.alterConfigs(), the server will persist it to metadata storage.

in new case with --enable-incremental, or when we removed the deprecated AdminClient.alterConfigs, here are what happened:

...