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. Cheers, Gerhard