You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Ken Tam <ke...@bea.com> on 2005/02/19 00:10:21 UTC

Beehive Beta1 public distribution release plan

I count 8 +1's and no dissenting/abstaining votes.  Thanks guys!

Here's a revised proposal, incorporating the feedback we've had, and the
broad outline of a plan  to get us there:

---

We're doing a Beehive Beta1 public distribution release.

a) Beehive as essentially feature complete for v1 -- on that basis alone
it seems an appropriate time to release another public distribution.
While I don't think we're prepared to unequivocally state that APIs are
actually frozen, it's fair to say that we expect only minor changes
between now and GA.
b) The last distribution release we did was several months ago (alpha)
and we've made huge strides since then.  A release now will make it much
easier for users to engage and provide a formal label for filing
issues/having discussions.
c) EclipseCon and TheServerSide Symposium are both just around the
corner, it would be great to have fresh downloadable bits available in
time for that (Feb 28-Mar 3, Mar 3-5 respectively).

The Beta1 release will be versioned as 0.8.z.

Goals:
1) public release available Mar 3/2005.
2) updated/additional documentation (relative to alpha), existing
samples working (in particular the JPetStore)
3) provide a reference point for bug reporting/discussion
4) dogfoodable for app building
5) documention on API stability -- we'll maintain a wiki where known
areas of API churn will be documented.

Non-goals:
1) API stability
2) strong guarantee of backwards compat
3) usable for production
4) complete documentation / samples

---

We should probably start by classifying JIRA issues as V1Beta vs. V1.
The only issues classed as V1Beta should be should be ones that block
our goals as defined above.  JIRA issue owners, please take some time to
look over your assigned issues and make this determination; I'll start
doing it as well, and make sure all current issues have owners.

Given the current quality level of the codebase, I expect most of the
work to hit our goals will come in terms of updating samples and docs
and making sure the distribution is dogfoodable for app building.  If
you've got cycles, start building a distribution and examining it from
that perspective.

We should shoot for picking a beta1 candidate revision # next Friday.