Freezing the Drupal API
Hi all, Recent discussions on the Consultants list has raised the issue of the cost of doing business using Drupal, notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API. I wonder if there would be any interest in forming a group to tackle this by identifying where the current API has potential for improvement and perhaps even writing some code! My aim would be that as of Drupal 5.0 with CCK, the published API would be treated as "stable" and changes to it would be resisted strongly. IMHO, if this could be achieved it would give Drupal a much more mature look and make it more attractive to large users. It would also increase the manpower available to work on future Drupal development because right now extra resources are being wasted maintaining the 4.5 and 4.6 trees, simply because the API changes between releases makes it impractical for many users to upgrade to 4.7. ...Richard.
Richard Archer wrote:
Recent discussions on the Consultants list has raised the issue of the cost of doing business using Drupal,
... which is irrelevant to the development list.
notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API.
If you don't like this policy, use something else.
I wonder if there would be any interest in forming a group to tackle this by identifying where the current API has potential for improvement and perhaps even writing some code!
My aim would be that as of Drupal 5.0 with CCK, the published API would be treated as "stable" and changes to it would be resisted strongly.
This would be preparation for a split of the project.
IMHO, if this could be achieved it would give Drupal a much more mature look and make it more attractive to large users.
For which this mailing list does not care.
It would also increase the manpower available to work on future Drupal development because right now extra resources are being wasted maintaining the 4.5 and 4.6 trees, simply because the API changes between releases makes it impractical for many users to upgrade to 4.7.
Your proposal sounds a lot like the end of development to me, so the manpower wouldn't be needed. Cheers, Gerhard
My aim would be that as of Drupal 5.0 with CCK, the published API would be treated as "stable" and changes to it would be resisted strongly.
I tend to agree with killes: Drupal's policy, since as long as I've known it, is to give nary a look to backwards compatibility, and that is incredibly *freeing* when it comes to *strong* development. This isn't to say that we don't understand that there is an issue with the inevitable upgrade, but this is why we: * provide instructions on theme and module upgrades. * don't release an update until the major third party components of Drupal are already upgraded. Roughly though, this sort of discussion comes up once every six months. -- Morbus Iff ( don't heckle the super-villain ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
* don't release an update until the major third party components of Drupal are already upgraded.
er.. but that's not what happened with 4.7. There was a lot of talk about premium and golden repositories to address this issue which appears to have tacitly dwindled into nothingness. -K
* don't release an update until the major third party components of Drupal are already upgraded.
er.. but that's not what happened with 4.7. There was a lot of talk about premium and golden repositories to address this issue which appears to have tacitly dwindled into nothingness.
What wasn't upgraded? -- Morbus Iff ( strive for mediocrity ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
er.. but that's not what happened with 4.7. There was a lot of talk about premium and golden repositories to address this issue which appears to have tacitly dwindled into nothingness.
What wasn't upgraded?
Somebody posted a lengthy list on the mailing list in early April (iirc it was Vertice or Unconed) - unsure whether they were important or not .. AFAIK, the list of 'major third party components' is non-existent atm.. I'll start a thread on that. -K
On 5/15/06, Karthik <narakasura@gmail.com> wrote:
Somebody posted a lengthy list on the mailing list in early April (iirc it was Vertice or Unconed) - unsure whether they were important or not ..
AFAIK, the list of 'major third party components' is non-existent atm.. I'll start a thread on that.
Well, in this article I discuss several ways of finding the important modules: http://growingventuresolutions.com/fed/drupal-installed-now-what-an-introduc... I believe that with a few exceptions, the modules on a plurality of those lists you will find the "major" modules. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
Well, in this article I discuss several ways of finding the important modules:
http://growingventuresolutions.com/fed/drupal-installed-now-what-an-introduc...
I believe that with a few exceptions, the modules on a plurality of those lists you will find the "major" modules.
I've just submitted a list of possible modules - please have a look-see and follow-up on that thread :) Thanks, -K
Morbus Iff wrote:
* don't release an update until the major third party components of Drupal are already upgraded.
er.. but that's not what happened with 4.7. There was a lot of talk about premium and golden repositories to address this issue which appears to have tacitly dwindled into nothingness.
What wasn't upgraded?
ecommerce, for one, has no upgrade path. -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
On 17 May 2006, at 4:27 AM, John Handelaar wrote:
ecommerce, for one, has no upgrade path. Ecommerce, if you read any of the numerous places you can get information for it, will only be released for 4.7 in another 2 or so week's time.
The release date for the 4.7 ecommerce package has been set for about ~1 month after the Drupal 4.7 release for quite a while now. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
On 17 May 2006, at 4:27 AM, John Handelaar wrote:
ecommerce, for one, has no upgrade path. Ecommerce, if you read any of the numerous places you can get information for it,
Yes, thanks, fully aware. I was answering the question actually asked, Adrian, not wilfully giving you something to take offence at :) Calm down... -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
Adrian Rossouw wrote:
On 17 May 2006, at 4:27 AM, John Handelaar wrote:
ecommerce, for one, has no upgrade path. Ecommerce, if you read any of the numerous places you can get information for it,
Yes, thanks, fully aware.
I was answering the question actually asked, Adrian, not wilfully giving you something to take offence at :)
Calm down...
To Adrian's credit, I didn't think he was offended, or needed to calm down. "There's no upgrade path" implies that there is... Well... No upgrade path. "It will be released ~1 month after 4.7 ships" implies that there is an upgrade path. Perhaps you meant, 'Ecommerce and its related modules weren't ready at the same time 4.7 shipped, preventing many sites from upgrading immediately.' I can imagine that's been frustrating for a number of sites, though I think it's a good thing that the ecommerce folks have taken the time to get things working against the stable 4.7 release. Ecommerce is a HUGE chunk of code, and considering the nature of the features it offers, an early but buggy release would be disastrous. --Jeff
Jeff Eaton wrote:
I was answering the question actually asked, Adrian, not wilfully giving you something to take offence at :)
Calm down...
To Adrian's credit, I didn't think he was offended, or needed to calm down.
Point taken. I'm *very* keen after the last couple of days to not kick off another row by accident :)
Perhaps you meant, 'Ecommerce and its related modules weren't ready at the same time 4.7 shipped, preventing many sites from upgrading immediately.'
Indeed yes - the original question was in the order of 'what key modules aren't 4.7 ready yet?'. Admittedly that was about 200 angry arguments ago... prolly shouldn't have bothered replying. -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
Hi, John Handelaar wrote:
Morbus Iff wrote:
* don't release an update until the major third party components of Drupal are already upgraded.
er.. but that's not what happened with 4.7. There was a lot of talk about premium and golden repositories to address this issue which appears to have tacitly dwindled into nothingness.
What wasn't upgraded?
ecommerce, for one, has no upgrade path.
E-Commerce is available it CVS, and we are working towards a release on the 1st June. Gordon.
Op woensdag 17 mei 2006 04:27, schreef John Handelaar:
ecommerce, for one, has no upgrade path.
Neither does flexinode. We dont even have a release date in mind. Please contact me in private, or comment in one of the numerous issues/bug threads when you want to help out. Bèr
On 16 May 2006, at 12:23 AM, Karthik wrote:
er.. but that's not what happened with 4.7. There was a lot of talk about premium and golden repositories to address this issue which appears to have tacitly dwindled into nothingness.
Yes. but we have dww now =) and we can now control who can commit to what. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API.
If you don't like this policy, use something else.
Gerhard Richard Archer is the maintainer of the menu system for Drupal, not an end user. Even if he was, we could reply in a more positive and constructive way.
Khalid B wrote:
notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API.
If you don't like this policy, use something else.
Gerhard
Richard Archer is the maintainer of the menu system for Drupal, not an end user.
I know who he is and what he has done for the menu system and I appreciate it.
Even if he was, we could reply in a more positive and constructive way.
That _was_ a positive and constructive answer. I don't see the Drupal development changing any time soon. You yourself pointed out how beneficial it is. So it is constructive to recommend to Richard to use something else if he doesn't like it. It will save him a lot of frustration and other ressources. Cheers, Gerhard
That _was_ a positive and constructive answer. I don't see the Drupal development changing any time soon. You yourself pointed out how beneficial it is. So it is constructive to recommend to Richard to use something else if he doesn't like it. It will save him a lot of frustration and other ressources.
I was commenting on HOW it was being said, not WHAT was being said. The WHAT part we agree on. The HOW part we don't ...
Khalid B wrote:
That _was_ a positive and constructive answer. I don't see the Drupal development changing any time soon. You yourself pointed out how beneficial it is. So it is constructive to recommend to Richard to use something else if he doesn't like it. It will save him a lot of frustration and other ressources.
I was commenting on HOW it was being said, not WHAT was being said.
The WHAT part we agree on. The HOW part we don't ...
The fact that I don't pour half a ton of sugar over my emails should be common knowledge by now. I try to keep things short, simple and to the point. Just use your imagination to add some "please", "would you", "kindly", etc. This is a technical discussion list. Nothing should be taken personal (unless where noted). Cheers, Gerhard
"Gerhard Killesreiter" wrote:
This is a technical discussion list. Nothing should be taken personal (unless where noted).
This is not personal. This is political. I encourage any other person or persons to join with me in saying "No, we will not tolerate verbal violence" from Mr. Killesreiter. Each and every time that he seeks to verbally abuse another, we must say "No." Each and every time he seeks to mask his violence with "That's just how I am", we must say "No, not here." Each and every time he seeks to belittle, demean, insult, or harm another individual we must say "No, not her and not him." If Mr. Killesreiter would see fit to argue, as staunchly and as emotionally as he wanted, against the substance or ideas of others, then perhaps we could see through an occasional bitter comment or cross word. But, rather than give even cursory reply to other people's thoughts and ideas, he uses this public Drupal-branded forum to exorcise his own anger and violence. This is inappropriate and is condoned by silence. To those who have recently spoken up: KhalidB, Gildas Cotomale, Richard Archer, Jeremy Epstein ... I applaud your individual action in the face of a bully, and you should all know that your action is important, it is meaningful and it is helpful. Further, it is personally meaningful to me to read your words, offered warmly, humorously and clearly. And this is personal. "Gerhard Killesreiter" wrote:
The fact that I don't pour half a ton of sugar over my emails should be common knowledge by now.
But you sure like to sugar coat your mean spirit, and hide behind your oppression of others as if it were just something you were born with. Respectful adults, no matter what their particular personality traits, should not be encouraged or allowed to "smooth over" their verbal abuse of other people just by saying "Oh, that's just how I am." Oppressions of all kinds have been lessened by people standing up to those like you, who would hide behind their weaknesses and fears by claiming "personality", "childhood learning" or other thin and unconvincing arguments. You are violent. You are verbally abusive. And you write as if you have some deep-seated belief that you are more important than others and that you have a "free pass" to be condescending "just because". I would be more than happy to introduce some useful reading resources if you would like to further understand why your behavior is not tolerable and is verbally violent and abusive. Know this: You shall not continue to remain unchallenged in your ongoing harsh tone, mean spirit, demeaning attitude, verbal abuse and violence toward others. I do not care who you are, how long you've been here, why you think it's okay for you to be verbally abusive or any other thing. Nor do I care what you do for Drupal. I refuse to slink away, remain silent, or watch you treat other people in this way. (Neither do I wish to antagonize you, and would much rather you simply got with the 21st century and showed a little respect to other human beings.) You may be as bitter and angry as you like in private, but you are in public, sir, and you should be reprimanded by the owner of this list, rather than coddled and glad-handed, as it seems you expect. I said you would not bully me, and you have temporarily halted your attacks. Now, I join with anyone else who will also stand, to tell you, loudly and clearly: Get over yourself, Mr. Killesreiter. Your "free pass" for verbal violence has expired. -- Gary
On 16 May 2006, at 08:19, Gary (Lists) wrote:
I encourage any other person or persons to join with me in saying "No, we will not tolerate verbal violence" from Mr. Killesreiter.
Each and every time that he seeks to verbally abuse another, we must say "No."
Each and every time he seeks to mask his violence with "That's just how I am", we must say "No, not here."
It is true that Gerhard can be a bit of a bully -- intentional or not. Sometimes his posts can come across as being inappropriate, and I've repeatedly hinted Gerhard to be more careful. In many ways, it is like burping and farting in public. It doesn't make you a criminal, but you can't expect people to be OK with it. It doesn't buy you a lot of respect. And you know what? FOSS development is a lot about building trust and respect with one another. If you can't get people to trust and respect you, you can't make things happen. Trust and respect is our currency. And for what it is worth, I don't support Gary's post either. -- Dries Buytaert :: http://www.buytaert.net/
Well. I just joined this mailing list to get a better feel for the Drupal Community. Interesting times, I guess ;-) Relax, people. Now I shall go back to my lurking state. Gaele
Gary (Lists) wrote:
"Gerhard Killesreiter" wrote:
I encourage any other person or persons to join with me in saying "No, we will not tolerate verbal violence" from Mr. Killesreiter.
Gary, there's an old saying about a pointing out the mote in one's eye when you have a log in your own that you should consider here.
I don't know that I'd accuse anyone here of being mean-spirited, but I have winced at quite a few comments I've seen on this list. I can't speak for everyone, but I certainly don't get paid for my efforts on behalf of Drupal and I'll only do it as long as it's fun. Being dismissive or derisive is a quick way to purge the list of casual contributors. Maybe that's the goal. -- Dan Ziemecki Philosopher. Curmudgeon. Nerd. On 5/16/06, Earl Miles <merlin@logrus.com> wrote:
Gary (Lists) wrote:
"Gerhard Killesreiter" wrote:
I encourage any other person or persons to join with me in saying "No, we will not tolerate verbal violence" from Mr. Killesreiter.
Guys, relax. Gerhard has his own style, maybe you think it's a bit raw, but it's far from bad. On the other hand, there were a lot of words said against my own various writings and very often I do not understand the problem. Different cultures, different languages... maybe saying "boo" is a sin where you live, but here, it's just a word.
Different cultures, different languages... maybe saying "boo" is a sin where you live, but here, it's just a word.
I think Karoly hit the nail on the head. Both sides of the issue should realize that this is a universal community here spanning the globe (no ETs yet though ...) We just need to be careful with the wording a little bit ...
On 16 May 2006, at 7:10 PM, Khalid B wrote:
Both sides of the issue should realize that this is a universal community here spanning the globe (no ETs yet though ...) I don't think chx is merely human.
real people need sleep. =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Tue, 2006-05-16 at 19:59 +0200, Adrian Rossouw wrote:
On 16 May 2006, at 7:10 PM, Khalid B wrote:
Both sides of the issue should realize that this is a universal community here spanning the globe (no ETs yet though ...) I don't think chx is merely human.
real people need sleep. =)
further evidence of the superhuman potential of chx. http://flickr.com/photos/tags/chxcannotbedistracted/
On Tue, 16 May 2006 20:48:14 +0200, Darrel O'Pry <dopry@thing.net> wrote:
On Tue, 2006-05-16 at 19:59 +0200, Adrian Rossouw wrote:
On 16 May 2006, at 7:10 PM, Khalid B wrote:
Both sides of the issue should realize that this is a universal community here spanning the globe (no ETs yet though ...) I don't think chx is merely human.
real people need sleep. =)
further evidence of the superhuman potential of chx. http://flickr.com/photos/tags/chxcannotbedistracted/
ENOUGH OF THIS BULLSHIT! I deeply regret the day when I shrugged and said to Robert he is free to post those pictures.
Op dinsdag 16 mei 2006 19:10, schreef Khalid B:
Both sides of the issue should realize that this is a universal community here spanning the globe (no ETs yet though ...)
Yes. Accidents happen. People misunderstand eachother. And cultures, or ideas about thing differ. Hell, even ego's differ :P But when people always comment with "that is the way I am" they are very aware of their rudeness. That should have been enough reason to NOT hit the reply button half of the times.... One personal tip is, please minimize the window when, or after, you are typing such a message. Walk out. Grab a beer. Or go to sleep. Then later on, open that mail again, read it through (says me, mr typo... :)) and you will find yourself rude, unrealistic, or at least unprofessional. Most often you will decide to just delete that message, possibly with red cheeks. Making Drupals code better every cycle is one thing. We are technicians, it is a very natural thing even! Becoming better, as a whole(!) appears to be a more difficult task. /We/ can prove that OSS is really also (or maybe really) about people. And about working together. Not just about the code, but also about the road to that code. (after all, is OSS not Just A Way Of Doing Stuff?) In OSS the community is often just as important as the product. Let us never forget that. Lets make thing better! (quote from Philips) Bèr
2006/5/14, Gerhard Killesreiter <gerhard@killesreiter.de>:
Richard Archer wrote:
Recent discussions on the Consultants list has raised the issue of the cost of doing business using Drupal,
... which is irrelevant to the development list.
sure..
notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API.
If you don't like this policy, use something else.
sure.. But why is your answer so agressive :(
I wonder if there would be any interest in forming a group to tackle this by identifying where the current API has potential for improvement and perhaps even writing some code!
My aim would be that as of Drupal 5.0 with CCK, the published API would be treated as "stable" and changes to it would be resisted strongly.
This would be preparation for a split of the project.
If I say : i don't agree, here is my poitn of view or make a critic, would it be the starting point of a fork ? :/
IMHO, if this could be achieved it would give Drupal a much more mature look and make it more attractive to large users.
For which this mailing list does not care.
It would also increase the manpower available to work on future Drupal development because right now extra resources are being wasted maintaining the 4.5 and 4.6 trees, simply because the API changes between releases makes it impractical for many users to upgrade to 4.7.
Your proposal sounds a lot like the end of development to me, so the manpower wouldn't be needed.
:D When the geek meet the business man..
Cheers, Gerhard
At 11:42 PM +0200 14/5/06, Gerhard Killesreiter wrote:
If you don't like this policy, use something else.
I realise I have that option. But I thought I'd first do something constructive to try to address the biggest problem I have with Drupal.
This would be preparation for a split of the project.
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. 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. 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. I am offering to help formulate a plan whereby these problems can be prevented or at least lessened in the future. ...Richard.
Richard Archer wrote:
At 11:42 PM +0200 14/5/06, Gerhard Killesreiter wrote:
If you don't like this policy, use something else.
I realise I have that option. But I thought I'd first do something constructive to try to address the biggest problem I have with Drupal.
That's ok to do, but if you have read this ML for any length of time, you'd have known how that would end.
This would be preparation for a split of the project.
My point is, there are already multiple forks of Drupal.
Apparently nobody agree with you.
There's the 4.5 branch, the 4.6 branch and the 4.7 branch.
These aren't forks. The main difference is that they aren't developed further.
When 4.8 is released it will have a maintainer appointed and there will be 4 forks.
Nope.
Plus the Bryght guys have their own version of Drupal.
Nope
I guess Civicspace does too.
Nope, CS is a Drupal distro. The main (and probably only) difference is that it has an installer.
Bèr often talks about his Sympal fork.
Sympal is mainly set of install scripts, as Ber told us just today.
This is a ludicrous and unnecessarily complex position to be in.
I am not going to look up ludicruous but complex it is not.
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.
Well, I fully admit that I rather write code than think about how to write code. Others however do quite like this. I believe there was a largish amount of discussion involved in the new forms API.
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.
It isn't "painful" if you don't insist in hacking everything up, if you wait long enough most of your contrib modules will be available and all you need to update yourself is your theme. Just one thought: The problem with people complaining about difficult upgrades is that Drupal is easy to customize and then the updates fail. Would it be written in C most people wouldn't dare to touch it. :p
I am offering to help formulate a plan whereby these problems can be prevented or at least lessened in the future.
Well, you're welcome, but I'd rather see you write code, too. :p Cheers, Gerhard
Richard Archer wrote:
At 4:21 AM +0200 15/5/06, Gerhard Killesreiter wrote:
Apparently nobody agree with you.
Well you don't. And you're loud enough to drown out any conversation anyone else might have about this.
I've stayed relatively quiet in this discussion, for there is no reason to throw wood on the fire, but it's worth my opinion at least being noted, that I do believe that API should be stable. It was a lot of work chasing the 4.7 API for my modules as it mutated. I'm sure doing so for 4.8 will be again. And again for 4.9/5.0 and again for whatever version comes after that. Quick: Ask me why I don't expect to have a lot of time to do core work in the future.
On 16 May 2006, at 7:13 AM, Earl Miles wrote:
I've stayed relatively quiet in this discussion, for there is no reason to throw wood on the fire, but it's worth my opinion at least being noted, that I do believe that API should be stable. This is why I don't want us to introduce FAPI 2.0 before it's finished, and has been living in contrib for a while.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 15-May-06, at 8:43 PM, Richard Archer wrote:
This would be preparation for a split of the project.
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.
Hate to hop in on this one, 'cause it's a fairly useless thread... but Bryght is far from a fork... our 4.6 differs from "vanilla" in a handful of backports and things we either didn't get into 4.6 in time or wanted to offer to folks now (and same will hold true for 4.7). And, yes, as noted later - very much in concert with the community... -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
Richard Archer wrote:
It would also increase the manpower available to work on future Drupal development This I don't understand - what use is having more manpower if you've effectively frozen (or at least chilled) core development?
I appreciate the rapid and large changes we've had over the last two versions can make it hard to keep up, and that can make Drupal an expensive option from the consultant perspective. But it wasn't always this way. I think I started looking at Drupal around version 4.1 or 4.2, and as far as I can remember the changes between versions were relatively minimal until we hit 4.6. More recently there are several factors that have sped up development and that's likely to continue for a few releases - but I have a feeling it will eventually settle down again (it might take a couple of years), and at that point Drupal will not only look like a mature product to 'large users' it will actually *be* one. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
It would also increase the manpower available to work on future Drupal development
what use is having more manpower if you've effectively frozen (or at least chilled) core development?
Chris the Curmudgeon Presents A Melodrama In 5 Short Paragraphs A frozen, or very slowly evolving API, IS NOT FROZEN CORE DEVELOPMENT. I will assume for the moment that this was a minor misunderstanding. Clearly the code and features on both side of an API can change and develop as long as the expected interface (you know, the I in API) doesn't change away from existing code. New functionality can be added to the API. New implementations of existing functionality can be added with new interfaces. New code on both sides can take advantage of such extensions. It hardly means the end of all creativity. Let me give an example from the real world. All this fun Web 2.0 stuff and Web 1.0 stuff we are doing? This HTTP thing? These files? It's all from standard Unix / POSIX / BSD APIs that have been cast in concrete for 20 or 30 years. The web? HTTP? AJAX? RSS? Built on TCP sockets. The BSD socket interface has not changed in any appreciable fashion for at least 20 years. Horrors! -- We are not tied to the track and the Southbound Limited is not steaming down upon us. :-)
Built on TCP sockets.
Drupal is not that multi layered so that this would be possible. Of course it would be great if we could achieve the Nurvana of Drupal, the Perfectness. But first, could anyone please tell me the Ultimate Target Of Drupal? 42. Regards NK
Another thing about the freeze. The date the API will be frozen is September 1. The same date for the code freeze. By then we should have visibility on what is in and what is out for the next release, and whether it warrants a 5.0 or still be a 4.8.
Hi Richard Sorry, I don't understand. Why would you want to upgrade if you haven't built the cost into your product? All you *need* to do is patch security holes. What is wrong with continuing to run drupal 4.5? The last place I worked still uses MS Office 97 which is almost 10 years old. I think you should charge large companies more and hence have the funds you need to follow the upgrade path (if that is necessary). .s Richard Archer wrote:
Hi all,
Recent discussions on the Consultants list has raised the issue of the cost of doing business using Drupal, notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API.
I wonder if there would be any interest in forming a group to tackle this by identifying where the current API has potential for improvement and perhaps even writing some code!
My aim would be that as of Drupal 5.0 with CCK, the published API would be treated as "stable" and changes to it would be resisted strongly.
IMHO, if this could be achieved it would give Drupal a much more mature look and make it more attractive to large users.
It would also increase the manpower available to work on future Drupal development because right now extra resources are being wasted maintaining the 4.5 and 4.6 trees, simply because the API changes between releases makes it impractical for many users to upgrade to 4.7.
...Richard.
Richard, On 15 May 2006, at 22:57, Richard Archer wrote:
Recent discussions on the Consultants list has raised the issue of the cost of doing business using Drupal, notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API.
I wonder if there would be any interest in forming a group to tackle this by identifying where the current API has potential for improvement and perhaps even writing some code!
re-thinking some of Drupal's APIs is a good thing. If that makes them more consistent, and less likely to change in future, that is great. I happily accept patches that clean up the APIs. However, I can't promise that they won't change because we won't officially freeze them. In practice, however, APIs might end up being frozen because there is no longer a need to change them. APIs evolve and mature too. The pager API, to name just one example, hasn't changed in 1-2 years. If you think you can help them mature in a clean and consistent manner, that is great. But, the focus should be to clean up APIs, not to freeze them. In pratice, a good API might eventually freeze itself. -- Dries Buytaert :: http://www.buytaert.net/
Sorry to weigh in here, but I wanted to give a non-coders point of view... One of the biggest challenges I personally face when upgrading my sites is the daunting task of trying to sort through, "ok... I delete all of the "core drupal files" and then untar the old ones, and then run the upgrade... wait, what are the core files again?" It might not seem like a hard process for people that does this all the time, but for someone like me, it is a lot of work to do a drupal upgrade. What I think would make Drupal THE killer CMS app is quite simply if we were to have a button somewhere in the admin section(Prompts the user only every 24hrs), displayed prominently that says: [ 3 new updates - Upgrade your Drupal! ] let me digress for a second... I use Ubuntu Linux. I use it because it's super duper easy. It's easier than Windows and OS X IMHO. I've used Linux for 10 years now. I can't code. Anyway, I use Ubuntu because of it being easy. Mostly each morning I'll see a button on my Gnome panel that let's me know some action is needed in order to make sure my system is up-to-date. I click it, it does it's magic, and poof, my system is happy. I don't have to touch config files, and am not even prompted to interact with the process. I don't see why we can have the same sort of system with Drupal. When I clicked on the "Upgraded your Drupal!" button, or link, it would go through and say: Please enter your UID1 username and password. [provided said user was in right role for upgrade notification] Performing upgrades... (grabs and does stuff in the background: makes a diff of files or whatever to use as a restore method if something goes wrong, backups db etc..) Presents the user with: Upgrade complete! Something that's super simple, easy and "Trae Proof"[tm] :) That is what we need. Sure, if you want to be uber-chx-geeky and hack everything with a hexedit tool or whatever, go for it! *grin* But for those of use who are end-users who just want to manage content and only fight with the editorial process, we need simple. Thanks, sorry for the long email. Trae On 5/16/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
Richard,
On 15 May 2006, at 22:57, Richard Archer wrote:
Recent discussions on the Consultants list has raised the issue of the cost of doing business using Drupal, notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API.
I wonder if there would be any interest in forming a group to tackle this by identifying where the current API has potential for improvement and perhaps even writing some code!
re-thinking some of Drupal's APIs is a good thing. If that makes them more consistent, and less likely to change in future, that is great. I happily accept patches that clean up the APIs. However, I can't promise that they won't change because we won't officially freeze them. In practice, however, APIs might end up being frozen because there is no longer a need to change them. APIs evolve and mature too. The pager API, to name just one example, hasn't changed in 1-2 years.
If you think you can help them mature in a clean and consistent manner, that is great. But, the focus should be to clean up APIs, not to freeze them. In pratice, a good API might eventually freeze itself.
-- Dries Buytaert :: http://www.buytaert.net/
-- Trae McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.com/
2006/5/16, Trae McCombs <traemccombs@gmail.com>:
Sorry to weigh in here, but I wanted to give a non-coders point of view...
One of the biggest challenges I personally face when upgrading my sites is the daunting task of trying to sort through, "ok... I delete all of the "core drupal files" and then untar the old ones, and then run the upgrade... wait, what are the core files again?"
It might not seem like a hard process for people that does this all the time, but for someone like me, it is a lot of work to do a drupal upgrade.
I see... And that's a reason why DAPI cannot be freezed by now : not enought mature yet :)
From next releases one will do the upgrade your way with ease because each module will have it's own directory.. But the discussion is not closed and the work is in progess.
What I think would make Drupal THE killer CMS app is quite simply if we were to have a button somewhere in the admin section(Prompts the user only every 24hrs), displayed prominently that says:
[ 3 new updates - Upgrade your Drupal! ]
By the same way, and easier install stuff is on the road :) Maybe later will we have notifications and automatic updates ? Let's wait and see :) [...Ubuntu is the way to follow...]
Something that's super simple, easy and "Trae Proof"[tm] :)
That is what we need.
Sure, if you want to be uber-chx-geeky and hack everything with a hexedit tool or whatever, go for it! *grin* But for those of use who are end-users who just want to manage content and only fight with the editorial process, we need simple.
Thanks, sorry for the long email. Trae
[...]
Trae McCombs wrote:
What I think would make Drupal THE killer CMS app is quite simply if we were to have a button somewhere in the admin section(Prompts the user only every 24hrs), displayed prominently that says:
[ 3 new updates - Upgrade your Drupal! ]
let me digress for a second...
I use Ubuntu Linux. I use it because it's super duper easy. It's easier than Windows and OS X IMHO. I've used Linux for 10 years now. I can't code. Anyway, I use Ubuntu because of it being easy.
Mostly each morning I'll see a button on my Gnome panel that let's me know some action is needed in order to make sure my system is up-to-date. I click it, it does it's magic, and poof, my system is happy. I don't have to touch config files, and am not even prompted to interact with the process.
I don't see why we can have the same sort of system with Drupal.
When I clicked on the "Upgraded your Drupal!" button, or link, it would go through and say: Please enter your UID1 username and password. [provided said user was in right role for upgrade notification]
Performing upgrades... (grabs and does stuff in the background: makes a diff of files or whatever to use as a restore method if something goes wrong, backups db etc..)
Presents the user with: Upgrade complete!
Something that's super simple, easy and "Trae Proof"[tm] :)
That is what we need.
Unless you are interested in wide open security holes and completely breaking sites, this is probably not what you need. Now, you know the backup+upgrade process is manual, so that - if something goes wrong, then you can roll back your site to a previous state, your original files and database values are not lost. Of course we can do automatic backups and rollbacks, if you trust the code this much - I don't (see also the next point) - your PHP files need to be writable by the webserver, which means that any malicious code which ends up on the webserver (in a typical shared hosting, and/or apache module based setup) can modify your PHP code, ie. somebody else on the same server can easily modify your site code, or some bug in the site code can be used to modify your code, or a PHP block/node can modify your site source code, etc. What a dream! Ps. this was also discussed here numerous times before. Goba
On Tuesday 16 May 2006 00:46, Dries Buytaert wrote:
If you think you can help them mature in a clean and consistent manner, that is great. But, the focus should be to clean up APIs, not to freeze them. In pratice, a good API might eventually freeze itself.
Just as important, I think, is that a good API is extensible. You can add features without breaking the old ones. I think the new Form API is a decent example here. We can add new types of elements without breaking existing ones. We can refactor where they are added without breaking them. We can add automatic regular expression validation to fields without breaking old code. A forward-looking design is just as important if not moreso than a non-changing design. Honestly, though, most of the 4.6 -> 4.7 changes didn't seem that drastic. Form API was the only one that seemed like it took a long time to do. Was I just not dealing with any of the really complicated stuff? :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
At 7:46 AM +0200 16/5/06, Dries Buytaert wrote:
I happily accept patches that clean up the APIs. However, I can't promise that they won't change because we won't officially freeze them.
"freeze" was the wrong word. I carefully proofread the body of my message before sending it but forgot about the subject. Anyway, it served to get my message some extra attention :) What I would like to see is for the Drupal API to be more complete, more robust and more consistent. With many thanks to Jaza, the menu system now has a more complete API in 4.7, and I think this will help in a big way when the time comes to rewrite huge chunks of the underlying code. I would like to see more areas of Drupal mature in this way. I intend to work on this in whatever time I can muster to spend on Drupal. If anyone wants to help, drop me a line. ...Richard.
On 16 May 2006, at 08:59, Richard Archer wrote:
I happily accept patches that clean up the APIs. However, I can't promise that they won't change because we won't officially freeze them.
"freeze" was the wrong word. I carefully proofread the body of my message before sending it but forgot about the subject. Anyway, it served to get my message some extra attention :)
What I would like to see is for the Drupal API to be more complete, more robust and more consistent.
Well, than we're on the same page! Improving APIs is a good thing. :) -- Dries Buytaert :: http://www.buytaert.net/
On 15 May 2006, at 22:57, Richard Archer wrote:
Recent discussions on the Consultants list has raised the issue of the cost of doing business using Drupal, notably the high cost of upgrading existing installations due to the ever-changing nature of Drupal's API.
In an attempt to discuss this problem without the discussion getting shot down, I shared my vision on my personal blog, Like that, I can filter out any comments that aren't thoughtful/constructive or that cause provocation. http://buytaert.net/backward-compatibility -- Dries Buytaert :: http://www.buytaert.net/
participants (26)
-
Adrian Rossouw -
Adrian Simmons -
Bèr Kessels -
Chris Johnson -
Dan Ziemecki -
Darrel O'Pry -
Dries Buytaert -
Earl Miles -
Gabor Hojtsy -
Gaele Strootman -
Gary (Lists) -
Gerhard Killesreiter -
Gildas Cotomale -
Gordon Heydon -
Greg Knaddison - GVS -
James Walker -
Jeff Eaton -
John Handelaar -
Karoly Negyesi -
Karthik -
Khalid B -
Larry Garfield -
Morbus Iff -
Richard Archer -
sime -
Trae McCombs