> On 25 Nov 2015, at 22:01, Vinod Kumar Vavilapalli <vino...@apache.org> wrote: > > Tx for your comments, Andrew! > > I did talk about it in a few discussions in the past related to this but yes, > we never codified the feature-level alpha/beta tags. Part of the reason why I > never pushed for such a codification is that (a) it is a subjective decision > that the feature contributors usually have the best say on and (2) voting on > the alpha-ness / beta-ness may not be a productive exercise in non-trivial > number of cases (as I have seen with the release-level tags, some users think > an alpha release is of production quality enough for _their_ use-cases). > > That said, I agree about noting down our general recommendations on what an > alpha feature means, what a beta feature means etc. Let me file a JIRA for > this.
maybe discuss having a list @ release time. As an example, s3 and encryption at rest shipped in beta stage... what's in 2.8 that "we don't yet trust ourselves?". Me, I'd put erasure coding in there just because I've no familiarity with it > > The second point you made is absolutely true. Atleast on YARN / MR side, I > usually end up traversing (some if not all of) alpha features and making sure > the corresponding APIs are explicitly marked private or public unstable / > evolving. I do think that there is a lot of value in us getting more > systematic with this - how about we do this for the feature list of 2.8 and > evolve the process? > > In general, may be we could have a list of ‘check-list’ JIRAs that we always > address before every release. Few things already come to my mind: > - Mark which features are alpha / beta and make sure the corresponding APIs, > public interfaces reflect the state + have people add JIRAs for the next version to actually mark things as stable/out of beta
