On 5/15/06, Richard Archer <drupal.org@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