[development] CVS HEAD, code freeze, zeitgeist

[Derek Wright]

On Aug 19, 2006, at 8:06 AM, Gerhard Killesreiter wrote:

> 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.

yeah, you're probably right.  as i said in my *original* message, i'm  
not dissatisfied with the status quo, i'm just a little uneasy.  core  
running too fast for (most of) contrib to catch up seems like a  
lingering problem, but it's not clear what, if anything, we can do to  
address it.  either people are using/depending on the modules, and  
they either update them themselves, or pay someone else to do it, or  
the module isn't really that useful and it will eventually become  
abandoned.  we should continue to cultivate more drupal developers in  
whatever ways we can (recruit your development-savvy friends, folks!)  
but that's a *completely* separate discussion from core development  
schedules, "golden contrib", etc.

once we're able to tag real releases of contribs with the version of  
core they work with (which will be explicit in their version numbers,  
in fact) and stop the madness of calling "cvs" a version of anything,  
a lot of the confusion and woes will go away.  this won't add any  
more development resources, and it won't automatically make more of  
contrib updated in a timely manner, but at least crap will be less  
confusing for everyone involved. ;)  modules that people care about  
*will* be updated eventually, and no one has to upgrade to the latest  
core just because it's out.

especially once contrib authors can maintain stable + dev branches of  
their modules against each version of the core API, it will be less  
painful for the entire drupal community to live with the fact that  
there will be a spread of core versions out there, not every site  
will upgrade right away (if ever), and yet new features can still be  
added to contribs that are compatible with older versions of core.   
dries will probably dislike this, since he'll argue this will just  
encourage folks to use older versions of core and therefore work on  
the latest release will slow down (at least, that's what he used to  
think -- i believe i've at least partially changed his perspective on  
this).  but i think that's backwards.  drupal's refusal to remain  
backwards compatible (which again, i think is great) is what  
encourages people to remain at older versions of core, not the  
continued availability of various contribs.  people not wanting or  
being able to upgrade is a fact.  we can either accept that and  
provide ways for people to cope, or not.

the "Drupal Version-Module Support Matrix" (http://drupal.org/node/ 
63491) will be very handy in all of this.  it'll be a way to quickly  
visualize what modules are in what degree of preparedness for each  
version of drupal core.  if core keeps moving fast, and contrib keeps  
struggling to keep up, then at least people will be able to easily  
see what subset of the "drupal ecosystem" exists in each version.

in spite of the fact that it seems like nothing's going to change wrt  
the core development cycle as a result of this thread, i still think  
the discussion has helped clarify some things. ;)  the tangential  
discussion about "project health" metrics and displays has certainly  
been useful, and is already generating concrete actions to make  
things better (thanks dries + webchick).  i certainly feel more clear  
about my unease, and how to cope with it...

-derek