[development] CVS HEAD, code freeze, zeitgeist

Gerhard Killesreiter gerhard at killesreiter.de
Sat Aug 19 15:06:28 UTC 2006

Derek Wright wrote:
> On Aug 19, 2006, at 5:08 AM, Bèr Kessels wrote:
>> Golden stars are -indeed- not going to magically bring me coding ninjas.
> one possible solution to my original concern about core running too fast 
> for contrib to keep up was the proposal for a longer *freeze* period.  i 
> see a few pros to this approach:
> 1) more time for contrib to catch up. ;)

There seems to be an assumption that people would update modules given 
enough time. IMHO (and if I am allowed to take myself as a reference) 
that's not true. I update my modules when /I/ need them to be be updated 
or if somebody else sends a patch (which typically means that the patch 
sender needed that module). Also, this usually happens _after_ the 
release of the new Drupal version because before core is released I have 
no reason to update the modules as most of my clients would not want me 
to install beta versions.

On occassion I develop a new site with the upcoming release in mind and 
then I might update modules early.

I don't think that this approach is wrong or has to change, btw.

Actually, I am angry about myself that I accepted some patches to 
event.module to keep it cvs compatible. This delays the back-merging of 
fixes into the stable branch since I need to remove these changes from 
the diff.

> 2) more time to work on hardening, testing, bug fixing for core itself
> 3) more time to work on documentation
> 4) more time to work on usability enhancements (so long as they're not 
> major and don't change the API)
> the downside, of course, is that it would delay the next furious round 
> of changes.  however, that might just be a good thing. ;)  2 major 
> releases a year instead of 3 isn't anything to be ashamed of.

I don't see doing us more than 2 releases a year anyway. The catch-up 
period for 4.7 was long enough and still many module weren't updated 
before the release. This is just how it works and nothing will change this.


More information about the development mailing list