incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Schmidt <>
Subject Re: releasing from incubator? -- was: Re: a beehive release and the JSR 181 TCK issue
Date Tue, 07 Jun 2005 08:00:21 GMT
Here is my opinion on the whole release issue, which has not changed
in 18 months since the first big discussion of releases and incubation

Full Disclosure:  While this is my opinion as a member of the
Incubator PMC, it is not necessarily the consensus of the PMC.  In
addition, I was once a BEA employee and am still a (recently inactive)
committer on the beehive project; however, I have been consistent in
my views on this issue regardless of what individual/company/project
has raised the issue.

Given (my assumptions):
1. (binary) releases are useful in building interest in a project,
which often leads to a stronger community; also, the process of doing
a release is useful for a project to go through while in incubation.
2. while in incubation (when a project is still trying to reach its
goals for a diverse, collaborative, meritocratic-based community),
Apache does not want a project to claim that it is a fully-endorsed
Apache project
3. incubation status is no reflection on the technical quality or
maturity of the code base

1. releases should be allowed and even encouraged while incubation
(personally, I don't care whether they're called "releases",
"Releases", or "official project release".
2. projects should a) include obvious notices regarding their
incubation status and the status of their releases (e.g. in the README
file, as part of the file name, and on their web site),  b) hold a
vote of their ppmc (which should include interested members of the
Incubator PMC), and c) should ensure their mentor approves of the
release and its process.
3. projects within incubation should not be given some arbitrary
technical boundary, such as preventing them from classifying a release
as "1.0" or "2.0", based on the history and stability of the code

Guess what?  When we (this list) spend literally hundreds of emails
discussing these issues in late 2003, we came up with a lose set of
guidelines that pretty much fit with what is described above.  See
 Note there is nothing in there that states a release can't be called
"official" or "1.0" or anything like that.  Howeverm, it must meet the
branding guidelines.

I suggest those who disagree with these written guidelines suggest
changes to them to be discussed and voted upon; otherwise, existing
projects today should follow the only documentation we have given

(ready for the inevitable flames to begin, possibly from some folks I
have a lot of respect for...)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message