[development] RFC: drupal as a moving target

[Larry Garfield]

On Tue, 29 Apr 2008 14:40:47 +0200, Ivan Sergio Borgonovo <mail at webthatworks.it> wrote:
> On Tue, 29 Apr 2008 12:24:00 +0200
> Jakob Petsovits <jpetso at gmx.at> wrote:
> 
>> Ivan, I feel your pain, I'm having a hard time with porting my
>> modules in time as well (in addition to "new features" work). The
>> problem does exist.
>>
>> However, what I miss from your mails is a constructive proposal how
>> to make it better. Even now, the APIs are not changed for the fun
>> of it but always come with a significant improvement. You request
>> that the core devs take care not to change stuff *without a good
>> reason*, but that's what they do already.
> 
> It depends on the weights you put in the equation.
> 
>> In that case, you disagree with the community (including me), and
>> we expect you to make concrete proposals which type of API changes
>> should be frozen under which exact circumstances, and present
>> compelling arguments why that is better than the status quo.
> 
> 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?  I can think of only 2 off hand; the utility function for doing WHERE IN clauses safely (which is backward-compatible) and the removal of db_num_rows(), which doesn't work across all databases, which is why it was removed.  The current database work is the first major overhaul of the database layer since I've been involved in Drupal (a little over 2.5 years now).  And yes, I am hoping that it is the last major overhaul for several more years; if we have to completely overhaul the API level again, it means I screwed up somewhere. :-(  

The D6 menu API was the first time the menu API had any serious changes in that period, too.  We're just now discussing changing the Filter system for the first time since, uh, 4.5?  Earlier?  The node system has changed fairly little overall, which is part of the problem with it.  The D6 FAPI is, at the API level, not a total rewrite, just a cleanup with a few extra features.  Taxonomy hasn't really changed since... 2003? :-)  Comments, do those *ever* change?  The user system is so old and unchanged it's scary.

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.

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.

> I already put my time and money on seeing this happen. And I took the
> risk on developing a quite complex module on Drupal. It will be hard
> to afford an upgrade once at the current state of affairs, it will be
> unmanageable to sustain a second upgrade at the current estimated
> cost. I'll survive back-porting sec patches to 5 so that the cost will
> be spread over a longer period. I rely on very few contrib modules so
> that will be feasible. But meanwhile I think my project will continue
> to grow... once it will reach 20K lines of code it will be of
> comparable size to Drupal... 

Perhaps this is a bit controversial to say, but I'll say it anyway.  If you're writing contrib modules that reach 20K lines of code, then either:

1) You need to refactor it into a suite of modules that are easier to manage and upgrade, which would be better code anyway.

2) You need to stop and just piece together existing modules in a smart way instead of rewriting several wheels.

3) You are Earl Miles and you're writing Panels 3.

So unless you're Earl Miles, a 20K module is a sign that you're doing something wrong in the first place.  

--Larry Garfield