junrao commented on a change in pull request #9001:
URL: https://github.com/apache/kafka/pull/9001#discussion_r498512579
##########
File path:
clients/src/main/java/org/apache/kafka/common/feature/SupportedVersionRange.java
##########
@@ -17,9 +17,16 @@
package org.apache.kafka.common.feature;
import java.util.Map;
+import java.util.Objects;
+import org.apache.kafka.common.utils.Utils;
/**
- * An extended {@link BaseVersionRange} representing the min/max versions for
supported features.
+ * An extended {@link BaseVersionRange} representing the min, max and first
active versions for a
+ * supported feature:
+ * - minVersion: This is the minimum supported version for the feature.
+ * - maxVersion: This the maximum supported version for the feature.
+ * - firstActiveVersion: This is the first active version for the feature.
Versions in the range
Review comment:
@kowshik : I was thinking what if we relax the current check by just
making sure that maxVersion of finalized is within the supported range.
Basically in your example, if supported minVersion goes to 2, it's still
allowed since it's less than maxVersion of finalized. However, if supported
minVersion goes to 7, this fails the broker since it's more than maxVersion of
finalized.
Your concern for the relaxed check seems to be around deploying a wrong
version of the broker by mistake. I am not sure if that's a big concern. If the
wrong broker affects maxVersion of finalized, the broker won't start. If the
wrong broker affects minVersion of finalized, if we deprecated slowly, it won't
impact the existing clients.
----------------------------------------------------------------
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
