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