Now that things are starting to get to a usable state, I think we should start the discussion as to what a 1.0 release will (roughly) look like and what it will mean in terms of changes to the way we are currently working. We are currently operating on what I would call a near-zero-constraints change policy that allows us to make any changes we like to the system, so long as everything works when we are done. As more people build on Rave, this will become difficult to maintain. I don't think we are quite there, yet, but we should have an understanding of what are the major features we want to have completed before stabilizing a release.
>From a feature perspective, I think everything we have now should be >solidified, but we also need a couple of new things that will be critical for >anyone looking to use Rave in the beginning. The list of new (major) features >I thought would fit well into a 1.0 release are as follows: 1) Team pages: A page with a group-owned set of widgets, OpenSocial Spaces 2) Profile pages: A place to render information & widgets placed by the user 3) Rave as an OAuth Producer Additionally, I think we really need to clean up and stabilize the object model and API, including tweaks to the current package structure to better support development and inclusion by downstream implementers. If everyone agrees we should start working toward a 1.0 release, I recommend that we start adding the critical features to that version in JIRA and then picking them off as we do our monthly releases and moving them to the appropriate 0.x release. As for the post 1.0 changes to how we as a community work, I will let those of you who are much more experienced in running an Apache project suggest the process improvements needed to properly balance development and maintainability in the open source world. Thoughts? I would especially like to hear from the community members who are building on Rave now as to whether or not the assumptions that prompted this e-mail hold true for them. -Matt
