I actually don't see consensus, but I also don't think this discussion should drag on. Just be prepared for user confusion, although it is hard to determine how many user's there actually are.
Ralph On Mar 16, 2012, at 10:19 AM, Arvind Prabhakar <[email protected]> wrote: > 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 >>>>> >>>>> >>>>> >>>>> >>> >>>
