Re: [DISCUSS] 2.0.0-alpha?
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 wrote: > > On 10/9/18 2:10 PM, Keith Turner wrote: > > On Tue, Oct 9, 2018 at 1:52 PM Keith Turner wrote: > >> > >> On Tue, Oct 9, 2018 at 12:53 PM Josh Elser wrote: > >>> > >>> > >>> > >>> On 10/9/18 12:44 PM, Keith Turner wrote: > On Sat, Oct 6, 2018 at 12:27 AM Christopher 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?
On 10/9/18 2:10 PM, Keith Turner wrote: On Tue, Oct 9, 2018 at 1:52 PM Keith Turner wrote: On Tue, Oct 9, 2018 at 12:53 PM Josh Elser wrote: On 10/9/18 12:44 PM, Keith Turner wrote: On Sat, Oct 6, 2018 at 12:27 AM Christopher 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?
On Tue, Oct 9, 2018 at 2:47 PM Sean Busbey wrote: > > On Tue, Oct 9, 2018 at 1:24 PM Keith Turner wrote: > > > > On Sat, Oct 6, 2018 at 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? > > > > 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?
On Tue, Oct 9, 2018 at 1:24 PM Keith Turner wrote: > > On Sat, Oct 6, 2018 at 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? > > 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?
On Mon, Oct 8, 2018 at 7:33 PM Christopher 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 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 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:ctubb...@apache.org] > > >> Sent: Saturday, October 06, 2018 12:28 AM > > >> To: accumulo-dev > > >> 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?
On Sat, Oct 6, 2018 at 1:37 PM Sean Busbey 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 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 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:ctubb...@apache.org] > > > Sent: Saturday, October 06, 2018 12:28 AM > > > To: accumulo-dev > > > 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?
On Sat, Oct 6, 2018 at 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? 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 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:ctubb...@apache.org] > > Sent: Saturday, October 06, 2018 12:28 AM > > To: accumulo-dev > > 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?
On Tue, Oct 9, 2018 at 1:52 PM Keith Turner wrote: > > On Tue, Oct 9, 2018 at 12:53 PM Josh Elser wrote: > > > > > > > > On 10/9/18 12:44 PM, Keith Turner wrote: > > > On Sat, Oct 6, 2018 at 12:27 AM Christopher 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?
On Tue, Oct 9, 2018 at 12:53 PM Josh Elser wrote: > > > > On 10/9/18 12:44 PM, Keith Turner wrote: > > On Sat, Oct 6, 2018 at 12:27 AM Christopher 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?
On Tue, Oct 9, 2018 at 12:53 PM Josh Elser wrote: > > > > On 10/9/18 12:44 PM, Keith Turner wrote: > > On Sat, Oct 6, 2018 at 12:27 AM Christopher 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?
On 10/9/18 12:44 PM, Keith Turner wrote: On Sat, Oct 6, 2018 at 12:27 AM Christopher 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?
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 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 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 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 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 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:ctubb...@apache.org] Sent: Saturday, October 06, 2018 12:28 AM To: accumulo-dev 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?
On Sat, Oct 6, 2018 at 12:27 AM Christopher 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
Re: [DISCUSS] 2.0.0-alpha?
> 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 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 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 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 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 > >> 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:ctubb...@apache.org] > >>>>>> Sent: Saturday, October 06, 2018 12:28 AM > >>>>>> To: accumulo-dev > >>>>>> 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?
On Mon, Oct 8, 2018 at 9:05 PM Josh Elser 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 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 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 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:ctubb...@apache.org] > > > >> Sent: Saturday, October 06, 2018 12:28 AM > > > >> To: accumulo-dev > > > >> 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?
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 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 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 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 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:ctubb...@apache.org] Sent: Saturday, October 06, 2018 12:28 AM To: accumulo-dev 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?
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 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 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 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 > 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:ctubb...@apache.org] > > > >> Sent: Saturday, October 06, 2018 12:28 AM > > > >> To: accumulo-dev > > > >> 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?
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 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 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 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:ctubb...@apache.org] > > >> Sent: Saturday, October 06, 2018 12:28 AM > > >> To: accumulo-dev > > >> 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?
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 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 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:ctubb...@apache.org] > >> Sent: Saturday, October 06, 2018 12:28 AM > >> To: accumulo-dev > >> 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?
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 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:ctubb...@apache.org] Sent: Saturday, October 06, 2018 12:28 AM To: accumulo-dev 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?
Ok cool yeah sounds good. +1 for Alpha On Sat, Oct 6, 2018 at 1:37 PM Sean Busbey 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 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 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:ctubb...@apache.org] > > > Sent: Saturday, October 06, 2018 12:28 AM > > > To: accumulo-dev > > > 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?
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 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 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:ctubb...@apache.org] > > Sent: Saturday, October 06, 2018 12:28 AM > > To: accumulo-dev > > 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?
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 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:ctubb...@apache.org] > Sent: Saturday, October 06, 2018 12:28 AM > To: accumulo-dev > 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?
+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:ctubb...@apache.org] Sent: Saturday, October 06, 2018 12:28 AM To: accumulo-dev 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?
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 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 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?
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 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 >
[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
