2009/4/7 Sean T Evans <[email protected]> > I think we need to look at the release process as a whole to prevent the > short vote time as well as the giant time between releases. Given the > amount of time since our last release, I don't think that three weeks is > really a ridiculous amount of time for prepping the release. > > These are my suggestions off the top of my head... > > We need a way to identify, reliably, when it's time to release. How do > do that I don't have a clue. People with more whole-project experience > will have to provide input on that. My initial thought is that any > community member should be able to call for a release vote. The vote > should simply be "Has enough changed to make it worthwhile for a typical > user to upgrade?" If the vote is yes, then we initiate our release > procedure. > > We then need a more formalized release procedure consisting of > branching/tagging, testing, notification to plugin/theme developers, > documentation, and then packaging, voting, releasing and followup.
I think between http://wiki.habariproject.org/en/Release_Checklist, http://wiki.habariproject.org/en/Release_Policy, and http://wiki.habariproject.org/en/Test_Procedure we have a pretty good start on a formal procedure, but of course we should learn from the failings of this release and improve things. -- Michael C. Harris, School of CS&IT, RMIT University http://twofishcreative.com/michael/blog IRC: michaeltwofish #habari --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
