A BIG +1 on the idea of time-boxing the release cycles. I think this has a lot of benefits over the current approach. IMHO 1. It helps to create a sense of stability around the product. 2. It alleviates some (not all) of the when-will-release-X-be-done questions. 3. It helps businesses that rely on Drupal better plan their own Drupal-based initiatives 4. It adds a certain amount of structure to the development life-cycle 5. It helps contributors because knowing the schedule they can focus their efforts on the things that are most important to them for THAT release I know there are down-sides as well. I think the added structure would require more effort to manage. I've seen some OS projects employ a rotating release-coordinator so that burden is shared. Just my 2 cents. On 2/20/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
(Crazy idea: should 4.7 be renamed 5.0? Would it be better to call it 5.0? It would have been, but with several beta's already released it's now too late. And besides if everyone listens to Adrian R. and implements his crazy/brilliant ideas 4.7 *will* look like a point release compared to 4.8... =D
There a lot of crazy (yet cool) ideas shaping up for Drupal 4.8/5.0. People should already start preparing their patches; I hope to use much shorter development cycles in future aiming towards 2-3 releases a year. I'm thinking about trying a time-based release cycle, where development is frozen at a predefined date. It sounds like something worth evaluating. It doesn't hurt to give it a try.
-- Dries Buytaert :: http://www.buytaert.net/