Hi Jun, KIP-1014 is explicitly NOT for EA features, since EA features need to be usable by non-developers.
I think it's important to be clear about this. Maybe "unreleased" would be a better name than "unstable" since people seem to have lots of different ideas about what "unstable" means, which are very different than the intention of this KIP. What do you think? For a developer making changes to the code, making an additional change to enable testing outside of JUnit should be fine. I think this is actually critical to making this work, since if we allow non-developers to use KIP-1014 features, we'll get bogged down in compatibility discussions (no matter what the KIP says). best, Colin On Wed, Jun 26, 2024, at 14:49, Jun Rao wrote: > 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 >> >> >> >> >> >>
