You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2018/10/06 04:27:30 UTC
[DISCUSS] 2.0.0-alpha?
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?
Christopher
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Oct 9, 2018 at 2:47 PM Sean Busbey <bu...@cloudera.com.invalid> wrote:
>
> On Tue, Oct 9, 2018 at 1:24 PM Keith Turner <ke...@deenlo.com> wrote:
> >
> > On Sat, Oct 6, 2018 at 1:36 PM Sean Busbey <bu...@cloudera.com.invalid> wrote:
> > >
> > > yes alphas please. Do we want to talk about expectations on time
> > > between alpha releases? What kind of criteria for beta or GA?
> >
> > There are a lot of changes in 2.0.0. I plan to spend a lot of time
> > kicking the tires on 2.0.0-alpha. It may be useful to set a tentative
> > deadline for 2.0.0 GA inorder to help anyone else planning to poke at
> > 2.0.0 prioritize and plan. Seems like somewhere around 1 to 4 months
> > after alpha for GA would be reasonable. Not sure what the exact time
> > should be, I just know too short is bad and too long is bad.
> >
>
> I'd really like us to put 2.0 GA readiness in terms of feature /
> correctness goals rather than a strict time limit.
I agree, goals should take precedence over a date. May still be nice
to set a tentative goal date for completing the goals. Where would be
a good place to post this list of 2.0 release criteria? Maybe a
Github issue with a checklist? Below are some goals I think would be
good for 2.0.
* Upgrade testing
* Performance testing
* Correctness testing
* Write examples projects that use new features.
* Review and/or write docs for new features and major changes.
For my testing I'll write it up as I go. If there is an issue, I
could comment about that testing on the issue.
>
> For example, I'd love to see some assurance of perf consistency.
> Solving those kinds of problems can be extremely time intensive and
> difficult to schedule in advance.
>
> --
> busbey
Re: [DISCUSS] 2.0.0-alpha?
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
On Tue, Oct 9, 2018 at 1:24 PM Keith Turner <ke...@deenlo.com> wrote:
>
> On Sat, Oct 6, 2018 at 1:36 PM Sean Busbey <bu...@cloudera.com.invalid> wrote:
> >
> > yes alphas please. Do we want to talk about expectations on time
> > between alpha releases? What kind of criteria for beta or GA?
>
> There are a lot of changes in 2.0.0. I plan to spend a lot of time
> kicking the tires on 2.0.0-alpha. It may be useful to set a tentative
> deadline for 2.0.0 GA inorder to help anyone else planning to poke at
> 2.0.0 prioritize and plan. Seems like somewhere around 1 to 4 months
> after alpha for GA would be reasonable. Not sure what the exact time
> should be, I just know too short is bad and too long is bad.
>
I'd really like us to put 2.0 GA readiness in terms of feature /
correctness goals rather than a strict time limit.
For example, I'd love to see some assurance of perf consistency.
Solving those kinds of problems can be extremely time intensive and
difficult to schedule in advance.
--
busbey
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
On Sat, Oct 6, 2018 at 1:36 PM Sean Busbey <bu...@cloudera.com.invalid> wrote:
>
> yes alphas please. Do we want to talk about expectations on time
> between alpha releases? What kind of criteria for beta or GA?
There are a lot of changes in 2.0.0. I plan to spend a lot of time
kicking the tires on 2.0.0-alpha. It may be useful to set a tentative
deadline for 2.0.0 GA inorder to help anyone else planning to poke at
2.0.0 prioritize and plan. Seems like somewhere around 1 to 4 months
after alpha for GA would be reasonable. Not sure what the exact time
should be, I just know too short is bad and too long is bad.
>
> a *lot* has changed in the 2.0 codebase.
> On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
> >
> > +1
> >
> > In addition to the reasons stated by Christopher, I think that it also provides a clearer signal to earlier adopters that the public API *may* change before the formal release. With a formal release candidate, I interpret that it signals that only bug-fixes would occur up and until the formal release.
> >
> > With the length of time that we take between minor and patch releases, the even longer time that it takes the customer base to upgrade and development cost that we have supporting multiple branches, taking some extra time now to solicit feedback seems prudent. While the specifics and implications of semver are clear, sometimes it seems that there is additional weight and additional perceived risk when changing major versions, an alpha version preserves our flexibility while still moving forward.
> >
> > Ed Coleman
> >
> > -----Original Message-----
> > From: Christopher [mailto:ctubbsii@apache.org]
> > Sent: Saturday, October 06, 2018 12:28 AM
> > To: accumulo-dev <de...@accumulo.apache.org>
> > Subject: [DISCUSS] 2.0.0-alpha?
> >
> > 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?
> >
> > Christopher
> >
>
>
> --
> busbey
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
On Sat, Oct 6, 2018 at 1:37 PM Sean Busbey <bu...@cloudera.com.invalid> wrote:
>
> And can we keep the master branch the one used for 2.0.0-* until 2.0.0
> is ready for candidates for a GA release?
I am in favor of that for now. We could delay creating a 2.0 branch
until someone starts making non 2.0 changes. If that never happens
before 2.0 GA, then nothing to do.
> On Sat, Oct 6, 2018 at 12:36 PM Sean Busbey <bu...@cloudera.com> wrote:
> >
> > yes alphas please. Do we want to talk about expectations on time
> > between alpha releases? What kind of criteria for beta or GA?
> >
> > a *lot* has changed in the 2.0 codebase.
> > On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
> > >
> > > +1
> > >
> > > In addition to the reasons stated by Christopher, I think that it also provides a clearer signal to earlier adopters that the public API *may* change before the formal release. With a formal release candidate, I interpret that it signals that only bug-fixes would occur up and until the formal release.
> > >
> > > With the length of time that we take between minor and patch releases, the even longer time that it takes the customer base to upgrade and development cost that we have supporting multiple branches, taking some extra time now to solicit feedback seems prudent. While the specifics and implications of semver are clear, sometimes it seems that there is additional weight and additional perceived risk when changing major versions, an alpha version preserves our flexibility while still moving forward.
> > >
> > > Ed Coleman
> > >
> > > -----Original Message-----
> > > From: Christopher [mailto:ctubbsii@apache.org]
> > > Sent: Saturday, October 06, 2018 12:28 AM
> > > To: accumulo-dev <de...@accumulo.apache.org>
> > > Subject: [DISCUSS] 2.0.0-alpha?
> > >
> > > 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?
> > >
> > > Christopher
> > >
> >
> >
> > --
> > busbey
>
>
>
> --
> busbey
Re: [DISCUSS] 2.0.0-alpha?
Posted by Mike Miller <mm...@apache.org>.
Ok cool yeah sounds good.
+1 for Alpha
On Sat, Oct 6, 2018 at 1:37 PM Sean Busbey <bu...@cloudera.com.invalid>
wrote:
> And can we keep the master branch the one used for 2.0.0-* until 2.0.0
> is ready for candidates for a GA release?
> On Sat, Oct 6, 2018 at 12:36 PM Sean Busbey <bu...@cloudera.com> wrote:
> >
> > yes alphas please. Do we want to talk about expectations on time
> > between alpha releases? What kind of criteria for beta or GA?
> >
> > a *lot* has changed in the 2.0 codebase.
> > On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
> > >
> > > +1
> > >
> > > In addition to the reasons stated by Christopher, I think that it also
> provides a clearer signal to earlier adopters that the public API *may*
> change before the formal release. With a formal release candidate, I
> interpret that it signals that only bug-fixes would occur up and until the
> formal release.
> > >
> > > With the length of time that we take between minor and patch releases,
> the even longer time that it takes the customer base to upgrade and
> development cost that we have supporting multiple branches, taking some
> extra time now to solicit feedback seems prudent. While the specifics and
> implications of semver are clear, sometimes it seems that there is
> additional weight and additional perceived risk when changing major
> versions, an alpha version preserves our flexibility while still moving
> forward.
> > >
> > > Ed Coleman
> > >
> > > -----Original Message-----
> > > From: Christopher [mailto:ctubbsii@apache.org]
> > > Sent: Saturday, October 06, 2018 12:28 AM
> > > To: accumulo-dev <de...@accumulo.apache.org>
> > > Subject: [DISCUSS] 2.0.0-alpha?
> > >
> > > 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?
> > >
> > > Christopher
> > >
> >
> >
> > --
> > busbey
>
>
>
> --
> busbey
>
Re: [DISCUSS] 2.0.0-alpha?
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
And can we keep the master branch the one used for 2.0.0-* until 2.0.0
is ready for candidates for a GA release?
On Sat, Oct 6, 2018 at 12:36 PM Sean Busbey <bu...@cloudera.com> wrote:
>
> yes alphas please. Do we want to talk about expectations on time
> between alpha releases? What kind of criteria for beta or GA?
>
> a *lot* has changed in the 2.0 codebase.
> On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
> >
> > +1
> >
> > In addition to the reasons stated by Christopher, I think that it also provides a clearer signal to earlier adopters that the public API *may* change before the formal release. With a formal release candidate, I interpret that it signals that only bug-fixes would occur up and until the formal release.
> >
> > With the length of time that we take between minor and patch releases, the even longer time that it takes the customer base to upgrade and development cost that we have supporting multiple branches, taking some extra time now to solicit feedback seems prudent. While the specifics and implications of semver are clear, sometimes it seems that there is additional weight and additional perceived risk when changing major versions, an alpha version preserves our flexibility while still moving forward.
> >
> > Ed Coleman
> >
> > -----Original Message-----
> > From: Christopher [mailto:ctubbsii@apache.org]
> > Sent: Saturday, October 06, 2018 12:28 AM
> > To: accumulo-dev <de...@accumulo.apache.org>
> > Subject: [DISCUSS] 2.0.0-alpha?
> >
> > 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?
> >
> > Christopher
> >
>
>
> --
> busbey
--
busbey
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Oct 8, 2018 at 7:33 PM Christopher <ct...@apache.org> wrote:
>
> I don't know the answers to these questions. I just want to put a
> stake in the ground before the Accumulo Summit, so we have a basis for
I am in favor of trying to do an alpha release and completing the
release notes before the summit. I can help with the release notes,
it may be at the 11th hour though.
> evaluation and testing, and answering some of these unknowns.
> On Mon, Oct 8, 2018 at 11:28 AM Josh Elser <el...@apache.org> wrote:
> >
> > I would like to know what the scope of 2.0 is. Specifically:
> >
> > * What's new in this 2.0 alpha that people that is driving the release?
> > * Is there anything else expected to land post-alpha/pre-GA?
> >
> > On 10/6/18 1:36 PM, Sean Busbey wrote:
> > > yes alphas please. Do we want to talk about expectations on time
> > > between alpha releases? What kind of criteria for beta or GA?
> > >
> > > a *lot* has changed in the 2.0 codebase.
> > > On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
> > >>
> > >> +1
> > >>
> > >> In addition to the reasons stated by Christopher, I think that it also provides a clearer signal to earlier adopters that the public API *may* change before the formal release. With a formal release candidate, I interpret that it signals that only bug-fixes would occur up and until the formal release.
> > >>
> > >> With the length of time that we take between minor and patch releases, the even longer time that it takes the customer base to upgrade and development cost that we have supporting multiple branches, taking some extra time now to solicit feedback seems prudent. While the specifics and implications of semver are clear, sometimes it seems that there is additional weight and additional perceived risk when changing major versions, an alpha version preserves our flexibility while still moving forward.
> > >>
> > >> Ed Coleman
> > >>
> > >> -----Original Message-----
> > >> From: Christopher [mailto:ctubbsii@apache.org]
> > >> Sent: Saturday, October 06, 2018 12:28 AM
> > >> To: accumulo-dev <de...@accumulo.apache.org>
> > >> Subject: [DISCUSS] 2.0.0-alpha?
> > >>
> > >> 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?
> > >>
> > >> Christopher
> > >>
> > >
> > >
Re: [DISCUSS] 2.0.0-alpha?
Posted by Josh Elser <el...@apache.org>.
Ah, yes. I think you're right. Thanks again :)
On 10/9/18 12:32 PM, Mike Miller wrote:
>> Didn't RFile summaries show up in 1.9 too? (maybe I'm inventing that)
>
> I think you are thinking of Sampling, that was released in 1.8.0, showing
> up in 1.9. I still get them confused. They both are similar and start
> with S.
>
> On Tue, Oct 9, 2018 at 12:03 PM Josh Elser <el...@apache.org> wrote:
>
>> Thanks, Mike.
>>
>> Didn't RFile summaries show up in 1.9 too? (maybe I'm inventing that)
>>
>> On 10/9/18 11:39 AM, Mike Miller wrote:
>>> I think once we collect all the changes in 2.0 (there are a lot) we will
>> be
>>> able to create some bullet points, picking out changes most interesting
>> to
>>> users. The new bulk import process Kieth, Mark and I worked on should be
>>> one. There are many new features that come along with it that weren't
>>> possible. There was all the work Mike did for usability that he is
>>> presenting at the summit and wrote a blog post about 2 years ago:
>>>
>> https://accumulo.apache.org/blog/2016/11/16/simpler-scripts-and-config.html
>>> Rfile Summaries was a big change but happened a while ago. Recently, the
>>> new Crypto service and new AccumuloClient builder are some other features
>>> that come to mind.
>>>
>>>
>>> On Mon, Oct 8, 2018 at 9:05 PM Josh Elser <el...@apache.org> wrote:
>>>
>>>> Frankly, planning a release without even an idea of what is going into
>> it
>>>> seems like a waste of time to me.
>>>>
>>>> I didn't ask these questions to try to squash such a release; I don't
>> think
>>>> they're particularly difficult to figure out. Just curious what the
>> release
>>>> notes would look like (as a user, this is what I would care about). I
>> don't
>>>> think I'm alone.
>>>>
>>>> On Mon, Oct 8, 2018, 19:33 Christopher <ct...@apache.org> wrote:
>>>>
>>>>> I don't know the answers to these questions. I just want to put a
>>>>> stake in the ground before the Accumulo Summit, so we have a basis for
>>>>> evaluation and testing, and answering some of these unknowns.
>>>>> On Mon, Oct 8, 2018 at 11:28 AM Josh Elser <el...@apache.org> wrote:
>>>>>>
>>>>>> I would like to know what the scope of 2.0 is. Specifically:
>>>>>>
>>>>>> * What's new in this 2.0 alpha that people that is driving the
>> release?
>>>>>> * Is there anything else expected to land post-alpha/pre-GA?
>>>>>>
>>>>>> On 10/6/18 1:36 PM, Sean Busbey wrote:
>>>>>>> yes alphas please. Do we want to talk about expectations on time
>>>>>>> between alpha releases? What kind of criteria for beta or GA?
>>>>>>>
>>>>>>> a *lot* has changed in the 2.0 codebase.
>>>>>>> On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com>
>>>> wrote:
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> In addition to the reasons stated by Christopher, I think that it
>>>>> also provides a clearer signal to earlier adopters that the public API
>>>>> *may* change before the formal release. With a formal release
>> candidate,
>>>> I
>>>>> interpret that it signals that only bug-fixes would occur up and until
>>>> the
>>>>> formal release.
>>>>>>>>
>>>>>>>> With the length of time that we take between minor and patch
>>>>> releases, the even longer time that it takes the customer base to
>> upgrade
>>>>> and development cost that we have supporting multiple branches, taking
>>>> some
>>>>> extra time now to solicit feedback seems prudent. While the specifics
>> and
>>>>> implications of semver are clear, sometimes it seems that there is
>>>>> additional weight and additional perceived risk when changing major
>>>>> versions, an alpha version preserves our flexibility while still moving
>>>>> forward.
>>>>>>>>
>>>>>>>> Ed Coleman
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher [mailto:ctubbsii@apache.org]
>>>>>>>> Sent: Saturday, October 06, 2018 12:28 AM
>>>>>>>> To: accumulo-dev <de...@accumulo.apache.org>
>>>>>>>> Subject: [DISCUSS] 2.0.0-alpha?
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>> Christopher
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] 2.0.0-alpha?
Posted by Mike Miller <mm...@apache.org>.
> Didn't RFile summaries show up in 1.9 too? (maybe I'm inventing that)
I think you are thinking of Sampling, that was released in 1.8.0, showing
up in 1.9. I still get them confused. They both are similar and start
with S.
On Tue, Oct 9, 2018 at 12:03 PM Josh Elser <el...@apache.org> wrote:
> Thanks, Mike.
>
> Didn't RFile summaries show up in 1.9 too? (maybe I'm inventing that)
>
> On 10/9/18 11:39 AM, Mike Miller wrote:
> > I think once we collect all the changes in 2.0 (there are a lot) we will
> be
> > able to create some bullet points, picking out changes most interesting
> to
> > users. The new bulk import process Kieth, Mark and I worked on should be
> > one. There are many new features that come along with it that weren't
> > possible. There was all the work Mike did for usability that he is
> > presenting at the summit and wrote a blog post about 2 years ago:
> >
> https://accumulo.apache.org/blog/2016/11/16/simpler-scripts-and-config.html
> > Rfile Summaries was a big change but happened a while ago. Recently, the
> > new Crypto service and new AccumuloClient builder are some other features
> > that come to mind.
> >
> >
> > On Mon, Oct 8, 2018 at 9:05 PM Josh Elser <el...@apache.org> wrote:
> >
> >> Frankly, planning a release without even an idea of what is going into
> it
> >> seems like a waste of time to me.
> >>
> >> I didn't ask these questions to try to squash such a release; I don't
> think
> >> they're particularly difficult to figure out. Just curious what the
> release
> >> notes would look like (as a user, this is what I would care about). I
> don't
> >> think I'm alone.
> >>
> >> On Mon, Oct 8, 2018, 19:33 Christopher <ct...@apache.org> wrote:
> >>
> >>> I don't know the answers to these questions. I just want to put a
> >>> stake in the ground before the Accumulo Summit, so we have a basis for
> >>> evaluation and testing, and answering some of these unknowns.
> >>> On Mon, Oct 8, 2018 at 11:28 AM Josh Elser <el...@apache.org> wrote:
> >>>>
> >>>> I would like to know what the scope of 2.0 is. Specifically:
> >>>>
> >>>> * What's new in this 2.0 alpha that people that is driving the
> release?
> >>>> * Is there anything else expected to land post-alpha/pre-GA?
> >>>>
> >>>> On 10/6/18 1:36 PM, Sean Busbey wrote:
> >>>>> yes alphas please. Do we want to talk about expectations on time
> >>>>> between alpha releases? What kind of criteria for beta or GA?
> >>>>>
> >>>>> a *lot* has changed in the 2.0 codebase.
> >>>>> On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com>
> >> wrote:
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> In addition to the reasons stated by Christopher, I think that it
> >>> also provides a clearer signal to earlier adopters that the public API
> >>> *may* change before the formal release. With a formal release
> candidate,
> >> I
> >>> interpret that it signals that only bug-fixes would occur up and until
> >> the
> >>> formal release.
> >>>>>>
> >>>>>> With the length of time that we take between minor and patch
> >>> releases, the even longer time that it takes the customer base to
> upgrade
> >>> and development cost that we have supporting multiple branches, taking
> >> some
> >>> extra time now to solicit feedback seems prudent. While the specifics
> and
> >>> implications of semver are clear, sometimes it seems that there is
> >>> additional weight and additional perceived risk when changing major
> >>> versions, an alpha version preserves our flexibility while still moving
> >>> forward.
> >>>>>>
> >>>>>> Ed Coleman
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Christopher [mailto:ctubbsii@apache.org]
> >>>>>> Sent: Saturday, October 06, 2018 12:28 AM
> >>>>>> To: accumulo-dev <de...@accumulo.apache.org>
> >>>>>> Subject: [DISCUSS] 2.0.0-alpha?
> >>>>>>
> >>>>>> 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?
> >>>>>>
> >>>>>> Christopher
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >
>
Re: [DISCUSS] 2.0.0-alpha?
Posted by Josh Elser <el...@apache.org>.
Thanks, Mike.
Didn't RFile summaries show up in 1.9 too? (maybe I'm inventing that)
On 10/9/18 11:39 AM, Mike Miller wrote:
> I think once we collect all the changes in 2.0 (there are a lot) we will be
> able to create some bullet points, picking out changes most interesting to
> users. The new bulk import process Kieth, Mark and I worked on should be
> one. There are many new features that come along with it that weren't
> possible. There was all the work Mike did for usability that he is
> presenting at the summit and wrote a blog post about 2 years ago:
> https://accumulo.apache.org/blog/2016/11/16/simpler-scripts-and-config.html
> Rfile Summaries was a big change but happened a while ago. Recently, the
> new Crypto service and new AccumuloClient builder are some other features
> that come to mind.
>
>
> On Mon, Oct 8, 2018 at 9:05 PM Josh Elser <el...@apache.org> wrote:
>
>> Frankly, planning a release without even an idea of what is going into it
>> seems like a waste of time to me.
>>
>> I didn't ask these questions to try to squash such a release; I don't think
>> they're particularly difficult to figure out. Just curious what the release
>> notes would look like (as a user, this is what I would care about). I don't
>> think I'm alone.
>>
>> On Mon, Oct 8, 2018, 19:33 Christopher <ct...@apache.org> wrote:
>>
>>> I don't know the answers to these questions. I just want to put a
>>> stake in the ground before the Accumulo Summit, so we have a basis for
>>> evaluation and testing, and answering some of these unknowns.
>>> On Mon, Oct 8, 2018 at 11:28 AM Josh Elser <el...@apache.org> wrote:
>>>>
>>>> I would like to know what the scope of 2.0 is. Specifically:
>>>>
>>>> * What's new in this 2.0 alpha that people that is driving the release?
>>>> * Is there anything else expected to land post-alpha/pre-GA?
>>>>
>>>> On 10/6/18 1:36 PM, Sean Busbey wrote:
>>>>> yes alphas please. Do we want to talk about expectations on time
>>>>> between alpha releases? What kind of criteria for beta or GA?
>>>>>
>>>>> a *lot* has changed in the 2.0 codebase.
>>>>> On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com>
>> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> In addition to the reasons stated by Christopher, I think that it
>>> also provides a clearer signal to earlier adopters that the public API
>>> *may* change before the formal release. With a formal release candidate,
>> I
>>> interpret that it signals that only bug-fixes would occur up and until
>> the
>>> formal release.
>>>>>>
>>>>>> With the length of time that we take between minor and patch
>>> releases, the even longer time that it takes the customer base to upgrade
>>> and development cost that we have supporting multiple branches, taking
>> some
>>> extra time now to solicit feedback seems prudent. While the specifics and
>>> implications of semver are clear, sometimes it seems that there is
>>> additional weight and additional perceived risk when changing major
>>> versions, an alpha version preserves our flexibility while still moving
>>> forward.
>>>>>>
>>>>>> Ed Coleman
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christopher [mailto:ctubbsii@apache.org]
>>>>>> Sent: Saturday, October 06, 2018 12:28 AM
>>>>>> To: accumulo-dev <de...@accumulo.apache.org>
>>>>>> Subject: [DISCUSS] 2.0.0-alpha?
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>> Christopher
>>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: [DISCUSS] 2.0.0-alpha?
Posted by Mike Miller <mm...@apache.org>.
I think once we collect all the changes in 2.0 (there are a lot) we will be
able to create some bullet points, picking out changes most interesting to
users. The new bulk import process Kieth, Mark and I worked on should be
one. There are many new features that come along with it that weren't
possible. There was all the work Mike did for usability that he is
presenting at the summit and wrote a blog post about 2 years ago:
https://accumulo.apache.org/blog/2016/11/16/simpler-scripts-and-config.html
Rfile Summaries was a big change but happened a while ago. Recently, the
new Crypto service and new AccumuloClient builder are some other features
that come to mind.
On Mon, Oct 8, 2018 at 9:05 PM Josh Elser <el...@apache.org> wrote:
> Frankly, planning a release without even an idea of what is going into it
> seems like a waste of time to me.
>
> I didn't ask these questions to try to squash such a release; I don't think
> they're particularly difficult to figure out. Just curious what the release
> notes would look like (as a user, this is what I would care about). I don't
> think I'm alone.
>
> On Mon, Oct 8, 2018, 19:33 Christopher <ct...@apache.org> wrote:
>
> > I don't know the answers to these questions. I just want to put a
> > stake in the ground before the Accumulo Summit, so we have a basis for
> > evaluation and testing, and answering some of these unknowns.
> > On Mon, Oct 8, 2018 at 11:28 AM Josh Elser <el...@apache.org> wrote:
> > >
> > > I would like to know what the scope of 2.0 is. Specifically:
> > >
> > > * What's new in this 2.0 alpha that people that is driving the release?
> > > * Is there anything else expected to land post-alpha/pre-GA?
> > >
> > > On 10/6/18 1:36 PM, Sean Busbey wrote:
> > > > yes alphas please. Do we want to talk about expectations on time
> > > > between alpha releases? What kind of criteria for beta or GA?
> > > >
> > > > a *lot* has changed in the 2.0 codebase.
> > > > On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com>
> wrote:
> > > >>
> > > >> +1
> > > >>
> > > >> In addition to the reasons stated by Christopher, I think that it
> > also provides a clearer signal to earlier adopters that the public API
> > *may* change before the formal release. With a formal release candidate,
> I
> > interpret that it signals that only bug-fixes would occur up and until
> the
> > formal release.
> > > >>
> > > >> With the length of time that we take between minor and patch
> > releases, the even longer time that it takes the customer base to upgrade
> > and development cost that we have supporting multiple branches, taking
> some
> > extra time now to solicit feedback seems prudent. While the specifics and
> > implications of semver are clear, sometimes it seems that there is
> > additional weight and additional perceived risk when changing major
> > versions, an alpha version preserves our flexibility while still moving
> > forward.
> > > >>
> > > >> Ed Coleman
> > > >>
> > > >> -----Original Message-----
> > > >> From: Christopher [mailto:ctubbsii@apache.org]
> > > >> Sent: Saturday, October 06, 2018 12:28 AM
> > > >> To: accumulo-dev <de...@accumulo.apache.org>
> > > >> Subject: [DISCUSS] 2.0.0-alpha?
> > > >>
> > > >> 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?
> > > >>
> > > >> Christopher
> > > >>
> > > >
> > > >
> >
>
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Oct 8, 2018 at 9:05 PM Josh Elser <el...@apache.org> wrote:
>
> Frankly, planning a release without even an idea of what is going into it
> seems like a waste of time to me.
>
> I didn't ask these questions to try to squash such a release; I don't think
> they're particularly difficult to figure out. Just curious what the release
> notes would look like (as a user, this is what I would care about). I don't
> think I'm alone.
We do need to finish these release notes. Working towards an Alpha
release will hopefully motivate finishing them. I created the
following issue, if anyone thinks something should be in the release
notes please add a comment.
https://github.com/apache/accumulo-website/issues/115
>
> On Mon, Oct 8, 2018, 19:33 Christopher <ct...@apache.org> wrote:
>
> > I don't know the answers to these questions. I just want to put a
> > stake in the ground before the Accumulo Summit, so we have a basis for
> > evaluation and testing, and answering some of these unknowns.
> > On Mon, Oct 8, 2018 at 11:28 AM Josh Elser <el...@apache.org> wrote:
> > >
> > > I would like to know what the scope of 2.0 is. Specifically:
> > >
> > > * What's new in this 2.0 alpha that people that is driving the release?
> > > * Is there anything else expected to land post-alpha/pre-GA?
> > >
> > > On 10/6/18 1:36 PM, Sean Busbey wrote:
> > > > yes alphas please. Do we want to talk about expectations on time
> > > > between alpha releases? What kind of criteria for beta or GA?
> > > >
> > > > a *lot* has changed in the 2.0 codebase.
> > > > On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
> > > >>
> > > >> +1
> > > >>
> > > >> In addition to the reasons stated by Christopher, I think that it
> > also provides a clearer signal to earlier adopters that the public API
> > *may* change before the formal release. With a formal release candidate, I
> > interpret that it signals that only bug-fixes would occur up and until the
> > formal release.
> > > >>
> > > >> With the length of time that we take between minor and patch
> > releases, the even longer time that it takes the customer base to upgrade
> > and development cost that we have supporting multiple branches, taking some
> > extra time now to solicit feedback seems prudent. While the specifics and
> > implications of semver are clear, sometimes it seems that there is
> > additional weight and additional perceived risk when changing major
> > versions, an alpha version preserves our flexibility while still moving
> > forward.
> > > >>
> > > >> Ed Coleman
> > > >>
> > > >> -----Original Message-----
> > > >> From: Christopher [mailto:ctubbsii@apache.org]
> > > >> Sent: Saturday, October 06, 2018 12:28 AM
> > > >> To: accumulo-dev <de...@accumulo.apache.org>
> > > >> Subject: [DISCUSS] 2.0.0-alpha?
> > > >>
> > > >> 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?
> > > >>
> > > >> Christopher
> > > >>
> > > >
> > > >
> >
Re: [DISCUSS] 2.0.0-alpha?
Posted by Josh Elser <el...@apache.org>.
Frankly, planning a release without even an idea of what is going into it
seems like a waste of time to me.
I didn't ask these questions to try to squash such a release; I don't think
they're particularly difficult to figure out. Just curious what the release
notes would look like (as a user, this is what I would care about). I don't
think I'm alone.
On Mon, Oct 8, 2018, 19:33 Christopher <ct...@apache.org> wrote:
> I don't know the answers to these questions. I just want to put a
> stake in the ground before the Accumulo Summit, so we have a basis for
> evaluation and testing, and answering some of these unknowns.
> On Mon, Oct 8, 2018 at 11:28 AM Josh Elser <el...@apache.org> wrote:
> >
> > I would like to know what the scope of 2.0 is. Specifically:
> >
> > * What's new in this 2.0 alpha that people that is driving the release?
> > * Is there anything else expected to land post-alpha/pre-GA?
> >
> > On 10/6/18 1:36 PM, Sean Busbey wrote:
> > > yes alphas please. Do we want to talk about expectations on time
> > > between alpha releases? What kind of criteria for beta or GA?
> > >
> > > a *lot* has changed in the 2.0 codebase.
> > > On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
> > >>
> > >> +1
> > >>
> > >> In addition to the reasons stated by Christopher, I think that it
> also provides a clearer signal to earlier adopters that the public API
> *may* change before the formal release. With a formal release candidate, I
> interpret that it signals that only bug-fixes would occur up and until the
> formal release.
> > >>
> > >> With the length of time that we take between minor and patch
> releases, the even longer time that it takes the customer base to upgrade
> and development cost that we have supporting multiple branches, taking some
> extra time now to solicit feedback seems prudent. While the specifics and
> implications of semver are clear, sometimes it seems that there is
> additional weight and additional perceived risk when changing major
> versions, an alpha version preserves our flexibility while still moving
> forward.
> > >>
> > >> Ed Coleman
> > >>
> > >> -----Original Message-----
> > >> From: Christopher [mailto:ctubbsii@apache.org]
> > >> Sent: Saturday, October 06, 2018 12:28 AM
> > >> To: accumulo-dev <de...@accumulo.apache.org>
> > >> Subject: [DISCUSS] 2.0.0-alpha?
> > >>
> > >> 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?
> > >>
> > >> Christopher
> > >>
> > >
> > >
>
Re: [DISCUSS] 2.0.0-alpha?
Posted by Christopher <ct...@apache.org>.
I don't know the answers to these questions. I just want to put a
stake in the ground before the Accumulo Summit, so we have a basis for
evaluation and testing, and answering some of these unknowns.
On Mon, Oct 8, 2018 at 11:28 AM Josh Elser <el...@apache.org> wrote:
>
> I would like to know what the scope of 2.0 is. Specifically:
>
> * What's new in this 2.0 alpha that people that is driving the release?
> * Is there anything else expected to land post-alpha/pre-GA?
>
> On 10/6/18 1:36 PM, Sean Busbey wrote:
> > yes alphas please. Do we want to talk about expectations on time
> > between alpha releases? What kind of criteria for beta or GA?
> >
> > a *lot* has changed in the 2.0 codebase.
> > On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
> >>
> >> +1
> >>
> >> In addition to the reasons stated by Christopher, I think that it also provides a clearer signal to earlier adopters that the public API *may* change before the formal release. With a formal release candidate, I interpret that it signals that only bug-fixes would occur up and until the formal release.
> >>
> >> With the length of time that we take between minor and patch releases, the even longer time that it takes the customer base to upgrade and development cost that we have supporting multiple branches, taking some extra time now to solicit feedback seems prudent. While the specifics and implications of semver are clear, sometimes it seems that there is additional weight and additional perceived risk when changing major versions, an alpha version preserves our flexibility while still moving forward.
> >>
> >> Ed Coleman
> >>
> >> -----Original Message-----
> >> From: Christopher [mailto:ctubbsii@apache.org]
> >> Sent: Saturday, October 06, 2018 12:28 AM
> >> To: accumulo-dev <de...@accumulo.apache.org>
> >> Subject: [DISCUSS] 2.0.0-alpha?
> >>
> >> 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?
> >>
> >> Christopher
> >>
> >
> >
Re: [DISCUSS] 2.0.0-alpha?
Posted by Josh Elser <el...@apache.org>.
I would like to know what the scope of 2.0 is. Specifically:
* What's new in this 2.0 alpha that people that is driving the release?
* Is there anything else expected to land post-alpha/pre-GA?
On 10/6/18 1:36 PM, Sean Busbey wrote:
> yes alphas please. Do we want to talk about expectations on time
> between alpha releases? What kind of criteria for beta or GA?
>
> a *lot* has changed in the 2.0 codebase.
> On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
>>
>> +1
>>
>> In addition to the reasons stated by Christopher, I think that it also provides a clearer signal to earlier adopters that the public API *may* change before the formal release. With a formal release candidate, I interpret that it signals that only bug-fixes would occur up and until the formal release.
>>
>> With the length of time that we take between minor and patch releases, the even longer time that it takes the customer base to upgrade and development cost that we have supporting multiple branches, taking some extra time now to solicit feedback seems prudent. While the specifics and implications of semver are clear, sometimes it seems that there is additional weight and additional perceived risk when changing major versions, an alpha version preserves our flexibility while still moving forward.
>>
>> Ed Coleman
>>
>> -----Original Message-----
>> From: Christopher [mailto:ctubbsii@apache.org]
>> Sent: Saturday, October 06, 2018 12:28 AM
>> To: accumulo-dev <de...@accumulo.apache.org>
>> Subject: [DISCUSS] 2.0.0-alpha?
>>
>> 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?
>>
>> Christopher
>>
>
>
Re: [DISCUSS] 2.0.0-alpha?
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
yes alphas please. Do we want to talk about expectations on time
between alpha releases? What kind of criteria for beta or GA?
a *lot* has changed in the 2.0 codebase.
On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman <de...@etcoleman.com> wrote:
>
> +1
>
> In addition to the reasons stated by Christopher, I think that it also provides a clearer signal to earlier adopters that the public API *may* change before the formal release. With a formal release candidate, I interpret that it signals that only bug-fixes would occur up and until the formal release.
>
> With the length of time that we take between minor and patch releases, the even longer time that it takes the customer base to upgrade and development cost that we have supporting multiple branches, taking some extra time now to solicit feedback seems prudent. While the specifics and implications of semver are clear, sometimes it seems that there is additional weight and additional perceived risk when changing major versions, an alpha version preserves our flexibility while still moving forward.
>
> Ed Coleman
>
> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Saturday, October 06, 2018 12:28 AM
> To: accumulo-dev <de...@accumulo.apache.org>
> Subject: [DISCUSS] 2.0.0-alpha?
>
> 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?
>
> Christopher
>
--
busbey
RE: [DISCUSS] 2.0.0-alpha?
Posted by Ed Coleman <de...@etcoleman.com>.
+1
In addition to the reasons stated by Christopher, I think that it also provides a clearer signal to earlier adopters that the public API *may* change before the formal release. With a formal release candidate, I interpret that it signals that only bug-fixes would occur up and until the formal release.
With the length of time that we take between minor and patch releases, the even longer time that it takes the customer base to upgrade and development cost that we have supporting multiple branches, taking some extra time now to solicit feedback seems prudent. While the specifics and implications of semver are clear, sometimes it seems that there is additional weight and additional perceived risk when changing major versions, an alpha version preserves our flexibility while still moving forward.
Ed Coleman
-----Original Message-----
From: Christopher [mailto:ctubbsii@apache.org]
Sent: Saturday, October 06, 2018 12:28 AM
To: accumulo-dev <de...@accumulo.apache.org>
Subject: [DISCUSS] 2.0.0-alpha?
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?
Christopher
Re: [DISCUSS] 2.0.0-alpha?
Posted by Christopher <ct...@apache.org>.
I think the benefits of an alpha release can be, and have been,
expressed elsewhere in the internet better than I could do it. But, in
short, an alpha is to solicit feedback from a wider audience, outside
the devs.
In ASF, release candidates are part of the process for making any
release, including an alpha release. So, we'd be voting on RC1 of
2.0.0-alpha. A release candidate can't substitute for a release of any
kind. They serve different purposes. A passing vote would mean that we
can more explicitly share it outside the ASF committers to get the
feedback that an alpha asks for. For example, we can publish the alpha
release to Maven Central and the ASF mirrors, as well as link on our
downloads page.
On Sat, Oct 6, 2018 at 11:11 AM Mike Miller <mm...@apache.org> wrote:
>
> Are there any benefits of having an extra release of alpha versus just
> building a release candidate with extended time for testing?
>
> On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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?
> >
> > Christopher
> >
Re: [DISCUSS] 2.0.0-alpha?
Posted by Mike Miller <mm...@apache.org>.
Are there any benefits of having an extra release of alpha versus just
building a release candidate with extended time for testing?
On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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?
>
> Christopher
>
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Oct 9, 2018 at 12:53 PM Josh Elser <el...@apache.org> wrote:
>
>
>
> On 10/9/18 12:44 PM, Keith Turner wrote:
> > On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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)
If no one raises any objections to feature freeze in this discuss
thread, we could add something to the alpha release vote about feature
freeze.
Re: [DISCUSS] 2.0.0-alpha?
Posted by Christopher <ct...@apache.org>.
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 <el...@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 <el...@apache.org> wrote:
> >>>
> >>>
> >>>
> >>> On 10/9/18 12:44 PM, Keith Turner wrote:
> >>>> On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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?".
Re: [DISCUSS] 2.0.0-alpha?
Posted by Josh Elser <el...@apache.org>.
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 <el...@apache.org> wrote:
>>>
>>>
>>>
>>> On 10/9/18 12:44 PM, Keith Turner wrote:
>>>> On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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?".
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
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 <el...@apache.org> wrote:
> >
> >
> >
> > On 10/9/18 12:44 PM, Keith Turner wrote:
> > > On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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.
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Oct 9, 2018 at 12:53 PM Josh Elser <el...@apache.org> wrote:
>
>
>
> On 10/9/18 12:44 PM, Keith Turner wrote:
> > On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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?
Re: [DISCUSS] 2.0.0-alpha?
Posted by Josh Elser <el...@apache.org>.
On 10/9/18 12:44 PM, Keith Turner wrote:
> On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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)
Re: [DISCUSS] 2.0.0-alpha?
Posted by Keith Turner <ke...@deenlo.com>.
On Sat, Oct 6, 2018 at 12:27 AM Christopher <ct...@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.
>
> Christopher