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 > >> > >> > >> > >> > >
signature.asc
Description: Digital signature
