kowshik commented on a change in pull request #9001: URL: https://github.com/apache/kafka/pull/9001#discussion_r496550557
########## File path: clients/src/main/java/org/apache/kafka/common/feature/FinalizedVersionRange.java ########## @@ -40,14 +40,16 @@ public static FinalizedVersionRange fromMap(Map<String, Short> versionRangeMap) /** * Checks if the [min, max] version level range of this object does *NOT* fall within the - * [min, max] version range of the provided SupportedVersionRange parameter. + * [min, first_active_version, max] range of the provided SupportedVersionRange parameter. Review comment: We need to keep the existing validation. Here is a case where `minVersionLevel < firstActiveVersion` is true, but still there are no incompatibilities: ``` SupportedVersionRange={minVersion=1, firstActiveVersion=4, maxVersion=7} FinalizedVersionRange={minVersionLevel=2, maxVersionLevel=6} ``` For example, the above can happen during step 1 of feature verison level deprecation. Imagine the following: * A supported feature exists with `SupportedVersionRange={minVersion=1, firstActiveVersion=4, maxVersion=7}` * The above feature is finalized at `{minVersionLevel=2, maxVersionLevel=6}` in ZK already. Then imagine a new Kafka release is deployed that raises `firstActiveVersion` for the supported feature from 1 -> 4 (in order to deprecate versions: 1,2,3). In such a case, during Kafka server startup (where we check for feature incompatibilities), we would run into the comparison cited above between the new `SupportedVersionRange` and existing `FinalizedVersionRange`. But it is not considered to be a case of incompatibility. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org