We have already made a lesser stable release (version 1.0.0-incubating) that was labeled as alpha in the RELEASE-NOTES file that accompanied it. From this thread, I see that the consensus is to call the 1.1.0 release a beta.
I would therefore like to proceed with the release, with the official version 1.1.0-incubating, and specifically labeled as "beta" in the release notes. Since we are not calling it a 1.1.0-incubating-stable or 1.1.0-incubating-GA, we do not risk implying the stability or correctness of the released artifacts. Thanks, Arvind Prabhakar On Sun, Mar 18, 2012 at 7:56 PM, Juhani Connolly <[email protected]> wrote: > On 03/17/2012 05:13 AM, Ralph Goers wrote: >> >> 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 > > > I wasn't going to mention it but since Ralph did: user confusion is > definitely a bad thing and that "beta" probably should be in the file > name... What reasons are there for it not being there? If we want to get > more users to try it, having those too lazy to read the readme file is not > going to make people more amenable to trying future release. > > I think regular releases are good, but we have to be honest with users what > they're getting into. Most people don't give any piece of software more than > one chance and if people aren't prepared to deal with some bugs and > incomplete features they should probably wait till a later version to try > flume ng. A clear filename would help avoid that confusion. > > >> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> > >
