Hi Christo,
> Can you share a link to the specific email which states this? Sorry I didn’t explain that clearly. The discussion about the command started in this email (the fourth bullet point): https://lists.apache.org/thread/n814nntv70bqs9o4q365z3k7bc76h56b In the next email, Colin stated that information from servers was preferred. In the next two email, José stated that the functionality could be done using existing local mechanism. They had further discussion on how to implement it using a new or existing RPC in next few emails. At the end, Justine decided to “keep the mapping in the tool”, as stated in the linked email in my previous email. The reason is just like what José had said that it can be done without the help of server. > With the change you are proposing what would the output of kafka-features be? Sorry again, I explained incorrectly in the previous email. `kafka-features.sh version-mapping` has always included unstable feature versions; KAFKA-19544 did not change this behavior. We only want to expose the new flag to users in this KIP. Actually, the problem is about the metadata version rather than specific version of feature. Take your example, the output of a stable MV looks like this: huangzhangyu@huangzhangyudeMacBook-Pro kafka % bin/kafka-features.sh version-mapping --release-version 4.1-IV1 metadata.version=27 (4.1-IV1) kraft.version=1 transaction.version=2 group.version=1 eligible.leader.replicas.version=1 share.version=0 streams.version=0 In contrast, the output of an unstable MV looks like this: huangzhangyu@huangzhangyudeMacBook-Pro kafka % bin/kafka-features.sh version-mapping --release-version 4.2-IV1 metadata.version=29 (4.2-IV1) kraft.version=1 transaction.version=2 group.version=1 eligible.leader.replicas.version=1 share.version=1 streams.version=1 You can see that share.version is 1 in the second output, and there is no message stating that 4.2-IV1 is unstable. The proposed output of 4.2-IV1 without the new flag should be an error message: “Unknown metadata.version ‘4.2-IV1’, Supported metadata version are: …”, because unstable versions are excluded. > if a preview feature is turned off by default what are you trying to protect > against? We want to prevent users from mapping an unstable metadata version and not knowing it is unstable. This exact concern was raised in the original PR review here: https://github.com/apache/kafka/pull/20248#pullrequestreview-3280931305 If I explain anything wrong, feel free to correct me. Best, Chang-Yu Huang From: Christo Lolov <[email protected]> Date: Tuesday, October 28, 2025 at 7:05 AM To: [email protected] <[email protected]> Subject: Re: [DISCUSS] KIP-1234: Move and Add Arguments to version-mapping Commands Heya! > Based on the > discussion<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fl1qszyjrnppz27ggcqr91q8b1b8tdstl&data=05%7C02%7Cchangyuh1919%40vt.edu%7Ca086425b45564951fa7c08de1611dc16%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638972463129998663%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qc5lne6ghS%2BBB1OsChHhgFlxbaY3bsgwxn3fw2cgVds%3D&reserved=0<https://lists.apache.org/thread/l1qszyjrnppz27ggcqr91q8b1b8tdstl>>, > they should work offline in both tools. Can you share a link to the specific email which states this? I read through the discussion and KIP, and while the discussion does state that the flag should be added to both tools I don't see a discussion about it being available offline for both. For the second part of the KIP let's take a particular example. Today, queues are in preview, they appear as share.version in the output of kafka-features describe and they are set to 0 by default (i.e. off). With the change you are proposing what would the output of kafka-features be? Or to phrase my question differently - if a preview feature is turned off by default what are you trying to protect against? A user not interested in a preview functionality won't even know it exists and a user interested in testing it would be following the discussion on how to enable it, no? Best, Christo On Mon, 27 Oct 2025 at 23:37, Huang, Chang-Yu <[email protected]> wrote: > > Hi Christo, > > Thanks for the comment! > > The version-mapping and feature-dependencies commands were added In KIP- > 1022<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-1022%253A%2BFormatting%2Band%2BUpdating%2BFeatures&data=05%7C02%7Cchangyuh1919%40vt.edu%7Ca086425b45564951fa7c08de1611dc16%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638972463130024909%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nFwYso7pbmXDLlQzUiYlPJRIVwgbik9e9JK%2FaM%2BKZfI%3D&reserved=0<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1022%3A+Formatting+and+Updating+Features>>. > Based on the > discussion<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fl1qszyjrnppz27ggcqr91q8b1b8tdstl&data=05%7C02%7Cchangyuh1919%40vt.edu%7Ca086425b45564951fa7c08de1611dc16%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638972463130043413%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5mm%2FdnAGAjdzaVVVzXneoWO8Gnkctc2j4uMBxfcRBXY%3D&reserved=0<https://lists.apache.org/thread/l1qszyjrnppz27ggcqr91q8b1b8tdstl>>, > they should work offline in both tools. In my point of view, users may be > confused by the inconsistency and doubt the two tools provide different > information. > > Yes. I believe that the flag is required in some testing senario. Before > KAFKA-19544, the version-mapping command doesn’t include unstable feature > versions. Now, the tool includes them without asking users. Adding a flag > whose default is false can prevent normal users from accidently using an > unstable feature versions while allowing advanced user to query on those > versions. > > Best, > Chang-Yu Huang > > From: Christo Lolov <[email protected]> > Date: Monday, October 27, 2025 at 10:43 AM > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] KIP-1234: Move and Add Arguments to version-mapping > Commands > Heya, > > Thanks for the KIP! > > I am not convinced that making > --bootstrap-server/--bootstrap-controller optional in kafka-features > is needed. I understand that there is a difference with how > kafka-storage works, but the two CLIs are meant to be used in > different situations - kafka-storage is meant to be used during a > setup leading to a working cluster while kafka-features allows dynamic > interactions with an already working cluster. I further understand > that you might want to use this tool in an automation, but I don't > quite understand to what purpose - this isn't dynamic information i.e. > it will only change during a new release and you can just point to > that release's kafka-storage tool to get the same information, no? > > I am more intrigued by the second part of the KIP. As far as I am > understanding it, you would like to see what features are unstable, or > at least which version numbers of a feature are unstable so that you > don't enable them accidentally? > > Best, > Christo
