Hi, Justine, Thanks for the reply.
Having "kafka-feature dependencies" seems enough to me. We don't need to include the dependencies in the output of "kafka-feature describe". We only support "dependencies" in kafka-feature, not kafka-storage. We probably should do the same for "version-mapping". bin/kafka-features.sh downgrade --feature metadata.version=16 --transaction.protocol.version=2 We need to add the --feature flag for the second feature, right? In "kafka-features.sh describe", we only show the IV string for metadata.version. Should we also show the level number? Thanks, Jun On Wed, Mar 27, 2024 at 1:52 PM Justine Olshan <jols...@confluent.io.invalid> wrote: > I had already included this example > bin/kafka-features.sh downgrade --feature metadata.version=16 > --transaction.protocol.version=2 // Throws error if metadata version is < > 16, and this would be an upgrade > But I have updated the KIP to explicitly say the text you mentioned. > > Justine > > On Wed, Mar 27, 2024 at 1:41 PM José Armando García Sancio > <jsan...@confluent.io.invalid> wrote: > > > Hi Justine, > > > > See my comment below. > > > > On Wed, Mar 27, 2024 at 1:31 PM Justine Olshan > > <jols...@confluent.io.invalid> wrote: > > > The feature command includes the upgrade or downgrade command along > with > > > the --release-version flag. If some features are not moving in the > > > direction mentioned (upgrade or downgrade) the command will fail -- > > perhaps > > > with an error of which features were going in the wrong direction. > > > > How about updating the KIP to show and document this behavior? > > > > Thanks, > > -- > > -José > > >
