[development] CVS HEAD, code freeze, zeitgeist
drupal at dwwright.net
Sun Aug 20 02:20:08 UTC 2006
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...
More information about the development