[development] Freezing the Drupal API

Jeremy Epstein jazepstein at gmail.com
Tue May 16 03:25:39 UTC 2006


I agree with Richard's ideas, but not with his plans ;-).

As one of the many developers who has witnessed and has had to become
familiar with the API change from 4.6 to 4.7, I am definitely in
support of Drupal's "constantly changing APIs" policy (if it's between
stable versions, of course - and it is). Had we not introduced FAPI,
and the many other (smaller) API changes, Drupal would be stuck with
its own mistakes, and would be unable to fix itself. In Drupal's case,
the benefits of better code far outweigh the drawbacks of difficult
upgrade paths.

Plenty of other examples (before my time) illustrate this point as
well, including the theme system overhaul from 4.4 to 4.5, and the
introduction of the node system itself in 3.0 (according to <a
href="http://cvs.drupal.org/viewcvs/drupal/drupal/CHANGELOG.txt?view=markup">the
changelog</a>, there was no node system in Drupal once upon a time!).
I would like to see plenty more such examples in the future. As such,
I am against freezing the APIs.

However, I do think that we should work towards making the APIs more
robust and longer-lasting, and that we should make more of an effort
to get them right in the first place, so that there is less need to
re-do them. I don't want a stable API to be a strict rule for Drupal,
but I'd like to see it happening more, as a side effect of good
program design.

I realise (as I'm writing) that what I'm saying doesn't really need
saying, because our aim always is to "get it right the first time",
and we are succeeding in doing this more and more (hopefully FAPI will
prove to be a good example of this, and FAPI 2.0 will not break the
FAPI 1.0 API). But I think that Richard has a point: Drupal does often
fall into the trap of "code first, think later", and we should
certainly make a conscious effort to do it the other way around
whenever possible.

And I also give my +1 to Gerhard finding more manners, particularly
for a fellow core developer such as Richard. If we can "think first,
code later", we can also "think first, write emails later".

Cheers,
Jaza.

On 5/16/06, Richard Archer <drupal.org at juggernaut.com.au> wrote:
> Hi all,
>
> Recent discussions on the Consultants list has raised the issue of
> the cost of doing business using Drupal, notably the high cost of
> upgrading existing installations due to the ever-changing nature
> of Drupal's API.
>
> I wonder if there would be any interest in forming a group to
> tackle this by identifying where the current API has potential
> for improvement and perhaps even writing some code!
>
> My aim would be that as of Drupal 5.0 with CCK, the published
> API would be treated as "stable" and changes to it would be
> resisted strongly.
>
> IMHO, if this could be achieved it would give Drupal a much more
> mature look and make it more attractive to large users.
>
> It would also increase the manpower available to work on future
> Drupal development because right now extra resources are being
> wasted maintaining the 4.5 and 4.6 trees, simply because the API
> changes between releases makes it impractical for many users to
> upgrade to 4.7.
>
>  ...Richard.
>


More information about the development mailing list