A BIG +1 on the idea of time-boxing the release cycles. I think
this has a lot of benefits over the current approach. <br>
<br>
IMHO <br>
<br>
1. It helps to create a sense of stability around the product. <br>
2. It alleviates some (not all) of the when-will-release-X-be-done questions. <br>
3. It helps businesses that rely on Drupal better plan their own Drupal-based initiatives<br>
4. It adds a certain amount of structure to the development life-cycle<br>
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<br>
<br>
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.<br>
<br>
Just my 2 cents.<br>
<br>
<br>
<br><br><div><span class="gmail_quote">On 2/20/06, <b class="gmail_sendername">Dries Buytaert</b> <<a href="mailto:dries.buytaert@gmail.com">dries.buytaert@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>> (Crazy idea: should 4.7 be renamed 5.0?<br>>> Would it be better to call it 5.0?<br>> It would have been, but with several beta's already released it's<br>> now too late. And besides if everyone listens to Adrian R. and
<br>> implements his crazy/brilliant ideas 4.7 *will* look like a point<br>> release compared to 4.8... =D<br><br>There a lot of crazy (yet cool) ideas shaping up for Drupal 4.8/5.0.<br>People should already start preparing their patches; I hope to use
<br>much shorter development cycles in future aiming towards 2-3 releases<br>a year. I'm thinking about trying a time-based release cycle, where<br>development is frozen at a predefined date. It sounds like something<br>
worth evaluating. It doesn't hurt to give it a try.<br><br>--<br>Dries Buytaert :: <a href="http://www.buytaert.net/">http://www.buytaert.net/</a><br><br></blockquote></div><br>