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