Hi, Colin, Thanks for the reply.
1. https://kafka.apache.org/protocol.html#The_Messages_ConsumerGroupDescribe lists ConsumerGroupDescribeRequest, whose latest version is unstable. 4. "As devlopers, they can change the code to do this if they want." Just to be clear. A developer could be able to test unstable MV/RPCs by enabling unstable.features.enable in a real cluster, right? "But I think it's important that this should NOT work in our actual Kafka releases" Are you saying unstable MV/RPCs can't be enabled in Kafka releases with unstable.features.enable set to true? How do we plan to enforce that? Jun On Wed, Jun 26, 2024 at 12:52 PM Colin McCabe <cmcc...@apache.org> wrote: > On Wed, Jun 26, 2024, at 12:09, Jun Rao wrote: > > 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? > > > > Hi Jun, > > Non-Java developers will always be using only stable APIs. Unstable APIs > are only available to JUnit tests (that run inside the JUnit JVM). > > > Should we explicitly mark unstable versions of PRC in > > https://kafka.apache.org/protocol.html? Currently, it's not clear which > > versions are unstable. > > > > Hmm, I don't think the unstable APIs should be documented at all in our > public docs. Since they're just "possibilities for the future" that haven't > actually been released. > > > 2. enable.unstable.features: Our current convention is to put enable in > the > > suffix in config names. > > > > OK. I changed it to "unstable.features.enable" > > > 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 > > > > OK. I added this to that section. > > > 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? > > > > As devlopers, they can change the code to do this if they want. But I > think it's important that this should NOT work in our actual Kafka > releases, to avoid blurring the lines between released features and > unreleased ones. > > > 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. > > I added a note that "prior to a release, all metadata versions for that > release must be stable." > > best, > Colin > > > > > > 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 > >> >
