I'd be hesitant to add too much to the KIP template. We should be careful to keep the barrier to entry low for new users.
On Wed, Jul 31, 2024, 13:24 Kirk True <[email protected]> wrote: > Hi Josep, > > Thanks for starting this conversation! > > Yes, for KIPs that span multiple releases, clearly defining the KIP’s > state for each release is very important. Perhaps the KIP template could be > updated to include a “Release Plan” section that includes entries that > include: > > - Version: future Apache Kafka release > - Status: one of Preview, Early access, Production, etc. > - Jira: umbrella Jira under which other Jiras relevant to that release > are kept > - Notes: Free-form notes as needed by KIP author > > Using KIP-848 as an example, the “Release Plan” section could look like > this: > > - 3.7 > - Status: Early access > - Jira: KAFKA-123 > - Notes: includes support for user-assigned partitions but not > subscriptions, server-side regex not included > - 3.8 > - Status: Preview > - Jira: KAFKA-234 > - Notes: includes support for subscriptions and lots of bug fixes > - 4.0 > - Status: Production > - Jira: KAFKA-345 > - Notes: includes feature parity with “CLASSIC” consumer groups > > Of course, the contents of the “Release Plan” section may need to change > over time, and it’s important that the KIP author(s) update it accordingly. > > Just a thought. > > Thanks, > Kirk > > > On Jul 31, 2024, at 9:43 AM, Josep Prat <[email protected]> > wrote: > > > > Hi Colin, > > > > I'm not attached to any names, I'm happy to change them. > > But from what I can guess from KIP-848 the order is EA -> Preview -> GA > > Maybe I'm mistaken. > > > > This is why this discussion is important so we all agree on the number of > > steps, order and names. > > > > I know finding a universal solution is maybe impossible but if we can > find > > one that fits most of the feature releases we had and we are planning > > currently would be great. > > > > Best, > > > > ------------------ > > Josep Prat > > Open Source Engineering Director, Aiven > > [email protected] | +491715557497 | aiven.io > > Aiven Deutschland GmbH > > Alexanderufer 3-7, 10117 Berlin > > Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen, > > Anna Richardson, Kenneth Chen > > Amtsgericht Charlottenburg, HRB 209739 B > > > > On Wed, Jul 31, 2024, 18:31 Colin McCabe <[email protected]> wrote: > > > >> Hi Josep, > >> > >> Thanks for bringing up this discussion. > >> > >> My impression was that "preview" was earlier than early access. > >> > >> In my mind, "preview" somewhat implies that the feature could be > >> incomplete or partial. For example, if someone said their game was a > >> "preview" I would expect kind of a demo. > >> > >> Early access (EA) means people can "access" it but it's "early". In > other > >> words, use at your own risk. > >> > >> What you are calling "production ready," I think we've sometimes called > >> generally available (GA) in the past. I don't have a strong preference > on > >> terms. > >> > >> I think no matter how much standardization we do, there will always be a > >> lot of discretion in these terms :) But maybe this helps clarify how > >> they've been used in the past? > >> > >> best, > >> Colin > >> > >> > >> On Wed, Jul 31, 2024, at 02:03, Josep Prat wrote: > >>> Hi Kafka devs, > >>> > >>> Lately we started using "early access", "production ready" and also > >>> "preview" to determine the grade of "production readiness" of the > >> features > >>> we deliver to our community. > >>> However, as far as I know, there is no official definition from the > >> Apache > >>> Kafka side on which are the graduation steps for features and what type > >> of > >>> "guarantees" each of these offer. > >>> > >>> I think we should agree on which terms we should use and what each of > >> these > >>> exactly mean in terms of reliability. So far it seems we have this > >>> graduation steps: > >>> - Early Access: Feature is just complete but not yet fully polished and > >>> maybe not used in production in many environments > >>> - Preview: Feature was early access before and it underwent at least a > >>> cycle of improvements and fixes and it's used in some production > >>> environments maybe > >>> - Production ready: Feature is officially released and it fulfills the > >>> expected initial needs > >>> > >>> Note that we don't offer any guarantees or SLA/SLO in the classical > term. > >>> > >>> Is this something we can agree on? What do those terms mean to you? Do > we > >>> need more steps? Or do we need less steps? > >>> > >>> Best, > >>> -- > >>> [image: Aiven] <https://www.aiven.io> > >>> > >>> *Josep Prat* > >>> Open Source Engineering Di > <https://www.google.com/maps/search/%0A%3E%3E%3E+Open+Source+Engineering+Di?entry=gmail&source=g>rector, > *Aiven* > >>> [email protected] | +491715557497 > >>> aiven.io <https://www.aiven.io> | < > >> https://www.facebook.com/aivencloud> > >>> <https://www.linkedin.com/company/aiven/> < > >> https://twitter.com/aiven_io> > >>> *Aiven Deutschland GmbH* > >>> Alexanderufer 3-7, 10117 Berlin > >>> Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen, > >>> Anna Richardson, Kenneth Chen > >>> Amtsgericht Charlottenburg, HRB 209739 B > >> > >
