Re: [development] Freezing the Drupal API
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
At 7:01 PM -0600 15/5/06, Greg Knaddison - GVS wrote:
Well, that is nice. But code is gold. Talk is silver. And talk of talk must be made of an even lesser metal.
That's a quaint mantra. Code can be gold but unless you perform sufficient analysis and design before coding, the code is likely to be something much less valuable than gold. What I see in Drupal is lots of code that was hacked together as a proof-of-concept then polished up a bit and committed. The inconsistencies in the Drupal API reflect this approach to development. At first glance the Drupal code looks very nice, but when you delve deeper you find that the coupling of the code is quite high. This is because the API is seen as secondary to the evolution of the code. What I want to do is get a group of people together to work on developing a much more rigid and robust API so that the code can be incrementally improved without impacting on contrib and custom modules. ...R.
Op dinsdag 16 mei 2006 03:01, schreef Greg Knaddison - GVS:
Bèr often talks about his Sympal fork.
It is not meant to be a fork, nor do I recall ever calling the two words in one sentence :) My aim is still to provide a distro, build alongsite and with Drupal. But with a different focus. With modules that are selected for their useability and developers-friendlyness. And with core tools for unit-tests, agile development and rapid protoyping (and probably a load of other buzzwords :) ). But a fork? No. I am even working on/with the railfrog team to build some completely different CMS from ground up because getting Drupal to serve these needs I have would indeed require a fork. But a fork with a lot of work ;). And maintaining such a fork is not what I would call fun. Its double the work, youll have to develop in two systems if your such a maintainer. So hereby: officcially and signed in blood (haha) no: I am not working on a fork. Sympal is (going to be) just a distro. A different toolset. Bèr
On 5/15/06, Bèr Kessels <ber@webschuur.com> wrote:
Op dinsdag 16 mei 2006 03:01, schreef Greg Knaddison - GVS:
Bèr often talks about his Sympal fork.
It is not meant to be a fork, nor do I recall ever calling the two words in one sentence :)
Hi, Just to be clear, you have a bad edit in the quoting in your email. Richard said Sympal was a fork. I replied that it wasn't. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
participants (3)
-
Bèr Kessels -
Greg Knaddison - GVS -
Richard Archer