[development] CVS HEAD, code freeze, zeitgeist

[Derek Wright]

On Aug 17, 2006, at 2:02 PM, Bèr Kessels wrote:

> The good news is that that means more people using, developing  
> testing and
> investing in older versions: these versions simply stay alive longer.

yet another example of why we need separate stable and dev branches  
for contrib for *each* version/branch of the drupal core API. ;)   
http://drupal.org/node/77562

that said, i have similar concerns with a lot of what ber raised.   
i've got 6 modules i personally maintain and there are about 4 others  
i've got commit access to and help out with.  a few (dba and diff)  
still aren't ported to 4.7.  it's going to be a lot of work to port  
the rest to HEAD.  i've got tons of functionality i want to add to  
these modules, but i simply don't have the time to do it all, try to  
keep my eye on core development and help out where i can, be the  
resident CVS guru, *and* port all my modules to the latest core API  
every 3 months...

i'm honestly torn.  on the one hand, it's great to have new stable  
releases with useful improvements frequently, so that more sites at  
least have *access* to the latest functionality if they want it.   
however, given a) the rapid pace, b) the utter disregard for  
backwards compatibility (which is great!), c) the therefore very real  
cost in developer hours to keep contrib/themes/translations up to  
date with the latest core, and d) our relatively limited development  
resources (horsepower to write/review/test all the code involved), i  
wonder if aiming for releases every 3-4 months is too short.  drupal  
core is great and all, but show me a drupal site *anywhere* that  
doesn't use at least *something* from crontrib. ;)  therefore, i know  
it's painful to admit, but we really do have to be concerned about  
not having core run off far in advance of contrib.

either i can keep all 10 modules up to date with HEAD all the time,  
or i can make them better, but, given the other constraints on my  
time, i can't really do much of both.  maybe the problem is that i'm  
trying to maintain too many things, but i don't see anyone else  
volunteering to take over any of these contribs. ;)

also, given that CCK in core is basically crippled as it stands (no  
fields) and yet CCK in contrib doesn't work w/ CCK in core, and  
flexinode isn't going to be ported to either 4.7 or 4.8 (according to  
ber), i have serious concerns about freezing.  dynamic content types  
are essential for basically every real drupal site i'm dealing with.   
if core isn't going to provide fields, we absolutely *must* have a  
plan for working fields in 4.8 contrib (and further acknowledge that  
core basically requires contrib to be functional 95% of the time).

i don't have a concrete proposal, but, since dries is fishing for  
"zeitgeist", i just wanted to register my unease (not dissatisfaction).

thanks,
-dww