Reading back over this whole thread, my understanding is that there is explicit support from some people for an alpha, but others have questioned the value of an alpha release. Some of the questions appear to be centered around concerns about communicating our goals and feature set for 2.0.0, and possibly an inadequate or unclear roadmap to a final 2.0.0 release.
I think those are valid questions and concerns, but I do not think they block an alpha. I think those issues can be addressed concurrently with an alpha. So, I'm going to prepare a release candidate for 2.0.0-alpha-1 and start a vote. Meanwhile, I encourage everyone to contribute in whatever way they feel they can, whether it's updating the draft release notes for 2.0.0, helping establish a more concrete roadmap to 2.0.0 from here, or in whatever other way they feel they can best contribute. Thank you for everybody for participating in this discussion. On Wed, Oct 10, 2018 at 11:21 AM Josh Elser <els...@apache.org> wrote: > > On 10/9/18 2:10 PM, Keith Turner wrote: > > On Tue, Oct 9, 2018 at 1:52 PM Keith Turner <ke...@deenlo.com> wrote: > >> > >> On Tue, Oct 9, 2018 at 12:53 PM Josh Elser <els...@apache.org> wrote: > >>> > >>> > >>> > >>> On 10/9/18 12:44 PM, Keith Turner wrote: > >>>> On Sat, Oct 6, 2018 at 12:27 AM Christopher <ctubb...@apache.org> wrote: > >>>>> > >>>>> Hi Accumulo devs, > >>>>> > >>>>> I'm thinking about initiating a vote next week for a 2.0.0-alpha > >>>>> release, so we can have an official ASF release (albeit without the > >>>>> usual stability expectations as a normal release) to be available for > >>>>> the upcoming Accumulo Summit. > >>>>> > >>>>> An alpha version would signal our progress towards 2.0.0 final, serve > >>>>> as a basis for testing, and give us something to share with a wider > >>>>> audience to solicit feedback on the API, configuration, and module > >>>>> changes. Of course, it would still have to meet ASF release > >>>>> requirements... like licensing and stuff, and it should essentially > >>>>> work (so people can actually run tests), but in an alpha release, we > >>>>> could tolerate flaws we wouldn't in a final release. > >>>>> > >>>>> Ideally, I would have preferred a 2.0.0 final at this point in the > >>>>> year, but I think it needs more testing. > >>>>> > >>>>> Does an alpha release next week seem reasonable to you? > >>>> > >>>> > >>>> I am in favor of an Alpha release. Also, Alpha releases imply feature > >>>> freeze in some projects. I am in favor of feature freeze. Is anyone > >>>> opposed to feature freeze? > >>>> > >>>> Below is what feature freeze means to me. > >>>> > >>>> We agree to avoid adding new features for 2.0 AND work on 2.0 will > >>>> focus on bug fixes and polishing features added before the Alpha. > >>>> This polishing work could result in API changes. If anyone really > >>>> wants to add a new feature, they should discuss it on the mailing > >>>> list. > >>> > >>> No concerns with an alpha also implying a feature-freeze. That does mean > >>> that it should be even more straightforward to have a complete list of > >>> the features landing in 2.0.0 ;) (which remains my only concern) > >> > >> Are you concerned about not completing the release notes before an > >> alpha vote? Or is your concern something else? > > > > Personally, I would like to see the release notes completed before > > 2.0.0-alpha is announced. I can't think of compelling reasons to > > complete it earlier than that. However, it seems critical to complete > > them before announcing. > > > > It's in the same line of thinking that Sean stated: > > > "I'd really like us to put 2.0 GA readiness in terms of feature / > correctness goals rather than a strict time limit." > > Such a major release like 2.0 without clear reasons why users should > care strikes me as very "so what?".
