Hi Proven, Thanks for the KIP. I think there is a need for this capability, for those of us who deploy from trunk (or branches dervied from trunk).
With regard to "unstable.metadata.versions.enable": is this going to be a documented configuration, or an internal one? I am guessing we want it to be documented, so that users can use it. If we do, we should probably also very prominently warn that THIS WILL BREAK UPGRADES FOR YOUR CLUSTER. That includes logging an ERROR message on startup, etc. It would be good to document if a release can go out that contains "future MVs" that are unstable. Like can we make a 3.8 release that contains IBP_4_0_IV0 in MetadataVersion.java, as an unstable future MV? Personally I think the answer should be "yes," but with the usual caveats. When the actual 4.0 comes out, the unstable 4.0 MV that shipped in 3.8 probably won't work, and you won't be able to upgrade. (It was unstable, we told you not to use it.) best, Colin On Fri, Jan 5, 2024, at 07:32, Proven Provenzano wrote: > Hey folks, > > I am starting a discussion thread for managing unstable metadata > versions > in Apache Kafka. > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1014%3A+Managing+Unstable+Metadata+Versions+in+Apache+Kafka > > This KIP is actually already implemented in 3.7 with PR > https://github.com/apache/kafka/pull/14860. > I have created this KIP to explain the motivation and how managing Metadata > Versions is expected to work. > Comments are greatly appreciated as this process can always be improved. > > -- > --Proven
