[development] Freezing the Drupal API

[Darrel O'Pry]

On Tue, 2006-05-16 at 11:24 +1000, Richard Archer wrote:
> 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.

The API is stable for a released version. 
Build on your version. By the time the next version is released the
upgrade tools will be even better than 4.6 -> 4.7. Keep your modules up
to date. Those of us who like to work on core will make sure you data
makes it through the upgrade. 

Some people do a lot of work to make the moving API possible. It is
stated drupal don't freeze.

And some of us do plan our Proof of Concepts. 

I will say all of this is moot and useless. Anyone who has explored
thoroughly CCK/Views/Workflows/Actions knows there is absolutely no
competition in the market. I think this kind of innovation comes from
the 'do as thou wilt, shall be the whole of the law' plan to drupal's
development. If you get what you did past the gate keepers... one of
which is that angsty curmudgeon killes which can be as difficult as the
passage between charbydis and scylla.

> 
> 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.

There are also a lot of people who will deal with the upgrade issues for
you. If you're having problems with personal hacks and modifications I
suggest you explore doing your hacks in you theme's or in some sort of
site specific module, at the very least maintain a patchset, or go to
full on revision control and keep your core drupal and contrib modules
as vendor branches and merge where necessary. Merges are not that
painful as long as you know drupal. 

> 
> 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.

Well no, drupal is a growing project and is experiencing iterative
development... wittgenstein's ladder comes to mind. Someone came up with
a good functional idea... the menu system. It got improved a while back,
then you came along and made it better. It is much easier to improve
upon existing things, than create new ones... So yeah code is gold, and
improvements are better.

> >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.


Richard... I don't know that many core function calls have changed with
the exception of the formAPI... I'm sure diffing 4.6 and 4.7 | grep
^function  will reveal just how little of the actual API changed. 

At that there isn't one 'DrupalAPI'.. There are like 7 or 8 apis... and
they are all being improved independently. 



ok thats my morning rant...