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 >>
