Thanks Juhani and Jarcec for your input. >From the thread it appears that we have a consensus on the following:
Version: 1.1.0-incubating Release Label: beta, as specified in the README file. Thanks, Arvind Prabhakar On Fri, Mar 16, 2012 at 1:09 AM, Jarek Jarcec Cecho <[email protected]> wrote: > I personally do not feel the need to put "beta" directly into version name. > However I agree with Juhani that this release should be marked as "beta" > quality at least in documentation or release notes with a list of known > issues if possible (for example FLUME-862, ...). > > Just my 2 cents worth, > Jarcec > > On Fri, Mar 16, 2012 at 10:36:11AM +0900, Juhani Connolly wrote: >> On 03/16/2012 02:22 AM, Arvind Prabhakar wrote: >> >On Tue, Mar 13, 2012 at 10:33 PM, Ralph Goers >> ><[email protected]> wrote: >> >>On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote: >> >> >> >>>On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers<[email protected]> >> >>>wrote: >> >>>>In Maven we do this all the time, both for Maven itself and the plugins. >> >>>>I recall doing it for Cocoon. >> >>>> >> >>>>http://archive.apache.org/dist/tomcat/tomcat-7/ >> >>>>http://archive.apache.org/dist/httpd/ >> >>>>http://archive.apache.org/dist/httpcomponents/httpclient/binary/ >> >>>>http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, >> >>>>which broke compatibility, had a beta) >> >>>>http://archive.apache.org/dist/jackrabbit/ >> >>>> >> >>>>In fact, I would say it is more the norm to do this than not. >> >>>> >> >>>>Again, I'm used to dealing with Maven users. They will assume that if it >> >>>>doesn't have alpha or beta in the version then it isn't one. >> >>>Seems a reasonable approach. How do you decide what is alpha vs what >> >>>is beta vs a regular release? is there some special implication of >> >>>alpha vs beta? >> >>That is exactly why I started off this conversation with "The only >> >>question I have is whether the community considers this release "stable" >> >>or "ready for production" use". It isn't so much a question of missing >> >>features, although that may be important, but whether it provides the >> >>minimum functionality to actually be used in production and there are no >> >>blocking bugs. If the PMC feels it isn't beta quality then don't call it >> >>one. But if it is it should be labeled as such. The difference between >> >>alpha and beta is simply a matter of how far the project feels the code is >> >>from being production ready. For example, an alpha release will usually >> >>contain something that gives an idea of the direction but isn't very >> >>usable. Beta software frequently can be used but no one is very confident >> >>in it. I guess the real question to ask is, if you had a business to run >> >>with your customers relying on your software would you be comfortable >> >>using it\? If the answer is no then it should be an alpha or beta >> >>release. As engineers many of us are never completely comfortable with >> >>people using our software for fear something might break. We need to get >> >>over that. >> Fwiw, we are currently using scribed for our log collection on >> production servers. We want to use flume NG but do not feel >> comfortable running it in production yet. Considering what Ralph >> said, for that reason personally I think this should be considered a >> beta release, and think that any documentation should encourage >> early adopters to try it, but believe that people mistakenly >> believing it is a stable release is going to cause a lot of pain >> to users as they figure out which features work properly and which >> don't. >> >> >>I guess in this case I would say are we at the point where we are >> >>recommending that Flume users use NG instead of OG. (It has to be one or >> >>the other). If the answer is NG then I don't think it should be a beta. >> >>If you want them to try NG but still rely on OG then it should be a beta. >> >> >> >Thanks Ralph. Since no objections have be raised, I feel that we are >> >in agreement regarding the naming of this release. Specifically, we >> >don't want to label it as beta and would like to encourage users to >> >adopt it in favor of the prior 0.9.x release. >> > >> >>Mind you, this criteria is just my opinion. Everyone is free to judge the >> >>code for themselves but this can be handled in 1 of 2 ways. 1) The project >> >>(i.e. PMC) decides, 2) The release manager makes the decision. In most >> >>communities he who does the work gets to make the decision but the PMC is >> >>responsible for the release so, of course, has the right to make the call. >> >> >> >For now I will proceed with calling this version 1.1.0-incubating. If >> >there is disagreement, we can call a vote to settle. Note that I am >> >actively working on the release so any disagreement will have to be >> >resolved soon. >> > >> >Thanks, >> >Arvind Prabhakar >> > >> > >> > >> > >> >>Ralph >> >> >> >> >> >> >> >> >> >>
