Hi, Colin, Thanks for the reply.
4. "A developer could modify the code to allow unstable features outside of JUnit, and then run whatever they want." Hmm, it's inconvenient for a developer to make some temporary change just to test an unstable feature outside of junit, right? Also, how does a user test an EA feature in a release? It's inconvenient for a user to change code and recompile the binary. Jun On Wed, Jun 26, 2024 at 1:38 PM Colin McCabe <cmcc...@apache.org> wrote: > On Wed, Jun 26, 2024, at 13:16, Jun Rao wrote: > > Hi, Colin, > > > > Thanks for the reply. > > > > 1. > https://kafka.apache.org/protocol.html#The_Messages_ConsumerGroupDescribe > > lists ConsumerGroupDescribeRequest, whose latest version is unstable. > > > > Hi Jun, > > I think that is a bug. > > > > > 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? > > A developer could modify the code to allow unstable features outside of > JUnit, and then run whatever they want. > > > > > "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? > > > > We can just unset the configuration key in KafkaRaftServer.scala, which is > not used by JUnit, but which is used by the normal broker and controller > startup processes. > > best, > Colin > > > 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 > >> >> > >> >
