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
