Approach (1) seems like a good way to handle stability concerns people
might have. If we explicitly distinguish between current and stable (i.e.,
not set them both to the latest release). It would be nice to do a VOTE for
calling a release stable.

I would use approach (2) for compatibility concerns. Ideally, I wouldn't
ship anything in a release unless we are sure we can preserve its
compatibility. If we really think a feature is not ready, we could always
guard them with private configs that devs or beta-testers could enable to
use. In the past, there have been proposals about labeling specific
features alpha and beta. I am open to considering it provided we define
what those terms mean, ideally in our compat guidelines.

On Wed, Apr 22, 2015 at 2:46 PM, Andrew Wang <[EMAIL PROTECTED]>
wrote:

Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB