dengziming commented on code in PR #12072: URL: https://github.com/apache/kafka/pull/12072#discussion_r858479425
########## core/src/main/scala/kafka/api/ApiVersion.scala: ########## @@ -1,500 +0,0 @@ -/* - * Licensed to the Apache Software Foundation (ASF) under one or more - * contributor license agreements. See the NOTICE file distributed with - * this work for additional information regarding copyright ownership. - * The ASF licenses this file to You under the Apache License, Version 2.0 - * (the "License"); you may not use this file except in compliance with - * the License. You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - */ - -package kafka.api - -import org.apache.kafka.clients.NodeApiVersions -import org.apache.kafka.common.config.ConfigDef.Validator -import org.apache.kafka.common.config.ConfigException -import org.apache.kafka.common.feature.{Features, FinalizedVersionRange, SupportedVersionRange} -import org.apache.kafka.common.message.ApiMessageType.ListenerType -import org.apache.kafka.common.record.RecordVersion -import org.apache.kafka.common.requests.ApiVersionsResponse - -/** - * This class contains the different Kafka versions. - * Right now, we use them for upgrades - users can configure the version of the API brokers will use to communicate between themselves. - * This is only for inter-broker communications - when communicating with clients, the client decides on the API version. - * - * Note that the ID we initialize for each version is important. - * We consider a version newer than another, if it has a higher ID (to avoid depending on lexicographic order) - * - * Since the api protocol may change more than once within the same release and to facilitate people deploying code from - * trunk, we have the concept of internal versions (first introduced during the 0.10.0 development cycle). For example, - * the first time we introduce a version change in a release, say 0.10.0, we will add a config value "0.10.0-IV0" and a - * corresponding case object KAFKA_0_10_0-IV0. We will also add a config value "0.10.0" that will be mapped to the - * latest internal version object, which is KAFKA_0_10_0-IV0. When we change the protocol a second time while developing - * 0.10.0, we will add a new config value "0.10.0-IV1" and a corresponding case object KAFKA_0_10_0-IV1. We will change - * the config value "0.10.0" to map to the latest internal version object KAFKA_0_10_0-IV1. The config value of - * "0.10.0-IV0" is still mapped to KAFKA_0_10_0-IV0. This way, if people are deploying from trunk, they can use - * "0.10.0-IV0" and "0.10.0-IV1" to upgrade one internal version at a time. For most people who just want to use - * released version, they can use "0.10.0" when upgrading to the 0.10.0 release. - */ Review Comment: Should we also add these doc comments to MetadataVersion -- 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. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
