[development] RFC: drupal as a moving target

Gerhard Killesreiter gerhard at killesreiter.de
Tue Apr 29 16:32:19 UTC 2008

Hash: SHA1

Larry Garfield schrieb:

>> I think the DB API is a good example. Beware I'm not criticizing the
>> current work. I love it.
>> Maybe when D6 DB API was planned that was the best thing to do. Now
>> we will see another change of DB API.
>> D7 DB API does really look as a good candidate to be frizzed for at
>> least 2 releases if not more if all the efforts needed will be put
>> into getting it right. Should this change be accompanied by another
>> FAPI change? Should the DB and FAPI change be accompanied by cosmetic
>> changes to other 10 helper functions?
>> I think that shouldn't happen for D8.
> What D6 database changes?

Exactly. Spreading of FUD is all I see.

> It's not like Drupal is an entirely new CMS every version.  Some of
> the APIs there are quite old and stable, perhaps too old and stable
> in many cases.

I think people looking for a higher ROI with Drupal based projects
should rather sponsor somebody working on old, crufty code in Drupal
core than to bitch and moan about our development process.

> As Earl noted, what's holding up contrib for D6 isn't massive
> changes to core.  It's that a half-dozen key contrib modules all
> decided to do major architectural redesigns at the same time as
> their D6 upgrade when they were changing APIs anyway.  (Views,
> Panels, CCK, ImageAPI/ImageCache/ImageField, etc.)  That's the hold
> up, not core, and that's not something that core development can
> even really control, even if it wanted to.

Maybe we could introduce a code of conduct for contrib authors to not
do major overhauls when a new version is due. Ie if I maintain a
module for D6 and D7 comes out, I port it straight away to a D7-1
version and then start a rewrite as D7-2.

Version: GnuPG v1.4.6 (GNU/Linux)


More information about the development mailing list