[development] Freezing the Drupal API

[Greg Knaddison - GVS]

On 5/15/06, Richard Archer <drupal.org at juggernaut.com.au> wrote:
> My point is, there are already multiple forks of Drupal.
>
> There's the 4.5 branch, the 4.6 branch and the 4.7 branch.
> When 4.8 is released it will have a maintainer appointed
> and there will be 4 forks. Plus the Bryght guys have
> their own version of Drupal. I guess Civicspace does too.
> Bèr often talks about his Sympal fork.

You keep using that word. I do not think it means what you think it means.

http://en.wikipedia.org/wiki/Fork_%28software_development%29

All of the parties involved in the "forks" you mention are maintaining
them in symphony, not in opposition.

> This is a ludicrous and unnecessarily complex position to
> be in. And all because IMHO insufficient thought has been
> put into building a robust, flexible API so that Drupal can
> be enhanced without having to hack on core or have the API
> whipped out from under your feet.

People have actively stated the motvation for not having a static API:
it encumbers innovation.  It's not insufficient thought, it's
sufficient thought that has been applied in a different way due to
different philosophies.

> It should not be so painful to upgrade from 4.5 to 4.6 that
> people stick with 4.5 for years after it has been superceded.

This is an unreasonable point of view.  People don't upgrade for a
variety of reasons and only one of them is how painful the process is.
 Software upgrades are hard to get right.  The companies that need an
easy upgrade path end up running systems that have had very little
innovation in 30 years (I worked in telecoms, I know of which I speak
on reliability vs. features).

I think everyone agrees that upgrades need to be reasonably easy - but
there is a delicate balance with innovation and in the case of Drupal
the desired philosophy has been stated, documented, and agreed (by
most, if not all).

> I am offering to help formulate a plan whereby these problems
> can be prevented or at least lessened in the future.

Well, that is nice.  But code is gold.  Talk is silver. And talk of
talk must be made of an even lesser metal.

Personally, my "talk" on the subject is that Drupal should version the
API and modules should be checked against the API version number prior
to being enabled.  The module maintainer is then given the additional
burden of updating the "compatable with XXX" flag in the .install
file.

Greg

-- 
Greg Knaddison | Growing Venture Solutions
Denver, CO | http://growingventuresolutions.com
Technology Solutions for Communities, Individuals, and Small Businesses