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. > > 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 > > > >
