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
