Hi Justine, Thanks for the update. Some comments below.
On Wed, Mar 13, 2024 at 10:53 AM Justine Olshan <jols...@confluent.io.invalid> wrote: > 4. Include an API to list the features for a given metadata version I am not opposed to designing and implementing this. I am just wondering if this is strictly required? Would having auto-generated documentation address the issue of not knowing which feature versions are associated with a given release version? Does it need to be a Kafka API (RPC)? Or can this be strictly implemented in the tool? The latest tool, which is needed to parse release version to feature version, can print this mapping. Is this what you mean by API? > 5. I'm going back and forth on whether we should support the > --release-version flag still. If we do, we need to include validation so we > only upgrade on upgrade. I am not sure how this is different from supporting multiple --feature flags. The user can run an upgrade command where some of the features specified are greater than what the cluster has finalized and some of the features specified are less than what the cluster has finalized. In other words, the KRaft controller and kafka-storage tool are going to have to implement this validation even if you don't implement --release-version in the tools. Thanks, -- -José