Hi, Colin, Thanks for restarting the discussion. A few comments.
1. "An unstable RPC version can be changed at any time, until it becomes stable." What's our recommendation to non-java developers? Should they start building a new version of an RPC until it is stable? Should we explicitly mark unstable versions of PRC in https://kafka.apache.org/protocol.html? Currently, it's not clear which versions are unstable. 2. enable.unstable.features: Our current convention is to put enable in the suffix in config names. 3. It would be useful to explicitly mention the removal of the following two configs in the public interfaces section. unstable.api.versions.enable unstable.feature.versions.enable 4. "Clusters can be created with unstable MVs, but only in JUnit tests." Hmm, we should allow developers to test unstable MVs in a real cluster, right? 5. "This also implies that if there are no stable MVs for a release, parsing will fail." So for every release, we need to have at least one stable MV in that release number (e.g 3.8)? It would be useful to document that. Jun On Tue, Jun 25, 2024 at 3:39 PM Colin McCabe <cmcc...@apache.org> wrote: > Hi all, > > We previously discussed this KIP for documenting how we deal with unstable > MetadataVersions. At that time, we didn't bring it to a vote. > > Proven handed this off to me, and I've made some changes to the proposal > since then: > > - I expanded the scope to also cover "RPCs with latestVersionUnstable" > > - I expanded the scope to cover other unstable KIP-584 features > (MetadataVersion is just one KIP-584 feature, after all) > > - Made a single configuration cover all of the above. Since it's silly to > enable an unstable MV, but have it fail because you have not also set some > other configurations to get unstable things. > > - Clarified that unstable features will be usable only from JUnit, nowhere > else > > - Added a "rejected alternatives" section > > - Clarified that there is no need to "reserve" previously used but no > longer extant unstable features, MVs, or RPCs. > > Please take a look. > > best, > Colin >
