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
