Yeah, I agree that your description matches reality better :)
By "document" do you have any suggestions where? The interface itself has
documentation. Were you thinking Wiki?
On Wed, Aug 12, 2015 at 3:48 PM, Grant Henke <ghe...@cloudera.com> wrote:
> This is a great idea!
>
> I do question the classifications a bit. @stable seams unreasonable as
> Kafka has not has a "major" release yet. I have typically thought of Kafka
> releases as 0.{major}.{minor}.{maintenance}. For instance 0.8.3 coming up
> has a significant amount of change. Though Kafka's release cycle could be
> changing and I may not understand the cycle/classification correctly.
>
> I am thinking something along the lines of:
> - unstable - can change at any time (i.e maintenance releases)
> - evolving - can break compatibility at minor releases (i.e. 0.8.3 may
> be incompatible
> with 0.8.2)
> - stable - will only break compatibility at major releases (0.8, 0.9, etc)
>
> Regardless the choice of the "contract", I do suggest we document this.
>
>
> On Wed, Aug 12, 2015 at 5:05 PM, Gwen Shapira <g...@confluent.io> wrote:
>
> > Hi Team Kafka,
> >
> > Ewen just added stability annotations to Apache Kafka (KAFKA-2429).
> >
> > In the same PR, we marked the new Consumer API as "unstable" since we are
> > still actively iterating on them. The goal is to mark them as "evolving"
> > before the next release and after one release to validate them, we will
> > mark them as "stable".
> >
> > When adding new public APIs, we encourage you to think of their stage of
> > development and annotate correctly.
> >
> > The usage is:
> >
> > - unstable - can change at any time
> > - evolving - can break compatibility at minor releases (i.e. 0.9 may be
> > incompatible with 0.8)
> > - stable - will only break compatibility at major releases (1.0, 2.0,
> etc)
> >
> > Enjoy!
> >
> > Gwen
> >
>
>
>
> --
> Grant Henke
> Software Engineer | Cloudera
> gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
>
