[development] Freezing the Drupal API

[Richard Archer]

At 5:31 PM -0400 15/5/06, Khalid B wrote:

>The core developers innovate as they see fit, and do not let the API freeze
>limit their creativity, the features to be implemented, or the overall
>flexibility, power and compactness of Drupal's core.

I know. This, along with "code is gold" is the Drupal mantra.
And I would argue that this attitude has to change. It is a
sign that Drupal is immature, without focus and not much more
than a plaything for the core developers.

This "moving target" API model makes Drupal frustrating for
someone building a site which they want to run in the long term.

And as for trying to build a business around Drupal... well,
there's surely a lot of money in helping people upgrade their
installations. But personally I want to be able to offer a
reliable, up-to-date, feature-rich hosting environment, and
all Drupal promises me is a world of hurt.

I would also argue that the lack of a robust API has a detrimental
effect on the quality of the code in Drupal. For a simple example,
trace through the code that displays a menu item and see how much
code is executed to perform this task! I think this is a good
example of where "code is gold" and not having a well-defined
API to work within has led code which is complex, convoluted and
inefficient.


>Perhaps it is best to spend energy on migration paths (e.g. Flexinode
>to CCK, forms updater, ...etc.) rather than freeze the API early.

I'm not talking about freezing the API early. I mentioned that
my goal would be to have a stable API for Drupal 5.0 with CCK.

And upgrade paths don't help people upgrade their custom modules.
I think this is where the most pain is felt with upgrades.

I realise there will always be major new features which require
changes to the API. But what I want to do is work to create a
robust API that will allow incremental changes to be made behind
the scenes without impacting so heavily on both contrib and
custom modules.

 ...R.