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
