I've been a bit hung up on the idea that since Derby has done several
"official releases" from within the Incubator (e.g., Version 10.0.2.1 at
http://incubator.apache.org/derby/derby_downloads.html#Official+Releases
), Beehive should be able to do the same thing. I think a lot of us
have been thinking that an "official release" would help to be able to
express to potential developers that this is a serious project, with
production-quality code.
I understand your points, though, and I think that as an alternative to
spending more cycles on this release, it would be very healthy for us to
focus solely on exiting the Incubator. We are totally committed to
building a real dev community around Beehive, and we need all the
guidance we can get in achieving that. From reading the Minimum Exit
Requirements, and from comments you've made in other threads, the main
issue that I'm aware of is an insufficient amount of discussion on the
beehive-dev list. I believe that this was at least partially due to the
state of the project as it entered the Incubator; most of the features
had been designed already. This may be why the beehive-user community
is more diverse than the community on beehive-dev. But we clearly need
to have more design/discussion in the list (and, incidentally, less of
it within JIRA issues). I feel that this is something we can address.
Beyond this major issue, do you feel that there are other hurdles for us
to clear before exiting the Incubator?
Thanks,
Rich
Noel J. Bergman wrote:
Cliff Schmidt wrote:
Noel J. Bergman wrote:
It just doesn't make sense to me to tell a community that believes it
has
a "1.0" quality product that they have to call it a "test snapshot".
Demo? Technology preview? Milestone? Happy Meal?
If we are keeping a project in incubation until its community is of
higher quality, why would we legislate terms that have to do with code?
You did notice the "Happy Meal" quip, right? If people want to try to come
up with a satisfactory label, fine. I'm curious.
it is entirely intentional and deliberate that projects in the Incubator
are
not permitted to make anything that smells like an official release.
I agree that they should not be permitted to make anything that
resembles an official *ASF-endorsed* released.
I am trying to separate code quality labels from branding.
I just don't see what that has to do with letting a project
indicate to its users what degree of stability their code
base is at or whether they expect to maintain backward
compatibility on their APIs
When users hear about a release, they assume a lot more than code quality.
Just as when they hear that a product reaches EOL, all of a sudden the
product sucks. In fact, there was an interesting thread on JAMES today:
http://mail-archives.apache.org/mod_mbox/james-server-user/200506.mbox/%3c
[EMAIL PROTECTED]
The end-user observed that "[the] initial impression we got was that Avalon
was so poorly designed or executed that it was closed due to embarrassment
or total frustration of the participating developers", when code quality had
nothing to do with the project's closure.
(often signalled by the "1.0" milestone).
Unless it is a Microsoft product, in which case don't touch it before 3.1.
;-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
