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/