Now that Beehive is formally in Beta, it's time to begin thinking about the road towards producing a 1.0 release. It's vitally important that as a project we don't just continuously churn and add new features, but that we also deliver a usable, useful, and stable platform upon which real applications can be built.
The best path (IMO) to 1.0 is primarily based upon tracking and resolving issues, and this takes effort from both the community of users and the community of developers involved in Beehive: - for users, please, please, please download the Beta distribution and use it (http://incubator.apache.org/beehive/downloads.html). Samples are a great starting point, but use it to build something real. Please open a JIRA issue for anything and everything that stands in your way... bugs, inadequate documentation, missing features, whatever. The only way we can know if we are there (at 1.0) or not is if the user community helps us! A key field for new JIRA issues is the "Priority" field. Big pain points for usefulness and usability should be classified as Blocker, Critical, or Major. Annoyances can be Minor or Trivial. No issue is too big or too small... we are looking for anything and everything! - for committers and other interested parties, it is really important that we stay on top of JIRA issues. Please look for incoming JIRA issues, evaluate, and take ownership of the ones in your area as appropriate. The key field here is "Fix Version". Anything flagged as "V1" is an issue we feel like we need to resolve prior to calling a 1.0 release done without jeopardizing overall stability. Anything flagged as "Unknown" (the default) implies that it hasn't gotten attention yet and needs a domain expert to give it a look. For bugs that are assigned for V1, please stay on top of them as best you can, because... The next logical question is when is the V1 release? In part the answer will lie in what happens in the two areas above over the next few weeks. The difference in rates between incoming V1 issues and resolution of those that have been identified will tell us a lot about whether we are converging on the goal or diverging... but the key metrics will be the total number of bugs flagged as "Fix by: V1" (ones we are seeking to close before release) and "Fix by: Unscheduled" (ones that need triage and attention from domain experts). I make these suggestions with no authority other than as someone interested in Beehive being successful and useful, and in my past experience the only way we can do this is to flush out the issues, track them, and deal with them. If someone has experience or perspective on how to approach the "getting to 1.0 release" process in a better or slightly different way, please speak up! Cheers! -- Kyle
