On Mar 13, 2012, at 5:59 PM, Ralph Goers wrote: > > On Mar 13, 2012, at 4:55 PM, Patrick Hunt wrote: > >> On Tue, Mar 13, 2012 at 4:31 PM, Ralph Goers <[email protected]> >> wrote: >>> >>> On Mar 13, 2012, at 4:08 PM, Eric Sammer wrote: >>> >>>> +1 on Arvind as 1.1.0 RM and on a 1.1.0 branch. +0 on labeling the release >>>> beta. Kind of feel like it's something to list in the README (on advice >>>> from phunt) and just release. Otherwise, it sounds like there will be a >>>> 1.1.0 final (which the ASF doesn't do). The advice I got when we tackled >>>> this with 1.0.0 was that the ASF produces releases, period. The quality can >>>> be indicated in the README (unless I misunderstood). >>> >>> I'm not sure whose advice you got but other projects do versions like >>> 1.2-beta all the time. IMO opinion labeling this 1.1-beta-incubating makes >>> it clear to everyone what it is even without reading the README, including >>> anyone typing the version in their pom - who almost never read those. >> >> A couple good items on the faq about this, see this for general details on >> what's a release: >> http://www.apache.org/dev/release.html#what > > Releases are packages that have been approved for general public release, > with varying degrees of caveat regarding their perceived quality or potential > for change. Releases that are intended for everyday usage by non-developers > are usually referred to as "stable" or "general availability (GA)" releases. > Releases that are believed to be usable by testers and developers outside the > project, but perhaps not yet stable in terms of features or functionality, > are usually referred to as "beta" or "unstable". Releases that only represent > a project milestone and are intended only for bleeding-edge developers > working outside the project are called "alpha". > > While this doesn't mean you have to include the terms in the name but I read > that as certainly implying it.
It is an important point that the name "1.1.0-beta" implies that we will have 1.1.0 RCs and then a 1.1.0 final. That's not what I thought I was voting for with a +1, I was thinking along the lines of what Apache Hadoop does by indicating the level of production use that occurred for the code line in the Release Notes. However, it's easy to see that the label Beta expresses a belief or opinion about the quality of the software. In reality, we already know of people using Flume NG in production, and how are we to know whether it meets a potential user's production requirements or not? Whether it qualifies as Alpha or Beta or Final is subjective, and waiting around for everyone to think a release version is "final" sounds like an exercise in frustration to me. Let's just put a list of features and a list of known issues (Bug Jiras) in the release notes. Let's worry less about labels and more about making well-designed software and releasing regularly. If we find any very serious issues with a given release, we always have the option of doing a point release to fix it. tl;dr: labels are too subjective, i say we leave it be Mike > >> >> Also this which goes into a bit more detail about types of releases: >> http://www.apache.org/dev/release.html#release-typeso >> >> In neither of these cases is Apache proscribing how to "name" your >> release however (although in the incubator you must indicate clearly >> "incubating"). Just the process that must be followed to consider >> something a release. >> >> My personal experience (granted it's with Hadoop related projects) is >> that they typically do not include the quality level in the name >> itself. Rather putting it in the readme, release notes, etc... But >> that's up to you. Some projects at Apache certainly do this, but none >> that i've been involved with. My personal preference is to have >> release notes that cover any issues the user should be aware of, >> rather than relying on "alpha/beta" labels in the name which might be >> confusing. > > Not every project is Hadoop. > > 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. > > Ralph
