Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By zahor on
After hearing Dries' keynote and subsequent discussions with module developers/maintainers, I'm (and I'm supported by many others who I heard talking about it) starting to think that 1 release per year (which I myself voted for...before I started on a module) may not be ideal.
Dries mentioned that they ran out of time when developing Drupal 6, and despite the 7 month code freeze, the majority of modules have not been ported to 6 yet. Some modules for 5 are still in early stages (pre-beta in some cases - like Ubercart!!) and tired and over-worked maintainers have to try to fix bugs in 5, then try to port to 6...and 7 is already on the horizon.
With the grand plans for ver. 7 (and I'm sure future versions), it's probable that some modules will need a major re-write, which would only add to the work.
Maintainers aren't the only people who lose out. For those at Drupalcon who were at the BOF where Drupal shops talked about upgrade challenges. When you spend several months on a large site (there's one I'm doing that I have been doing for about 8 months now! (this is more client changing scope over and over...but still) - but let's say you spend 4-6 [larger shops may crank them out faster, but when you're the sole Drupal developer, it's a different story]), you usually end with a short time (a year and a half), before your Drupal version is no longer supported and so you no longer get security updates. Sure this may add some more business for you or your company, but I think more than anything else, it may just eventually over work already over worked Drupal developers.
What does the community think about this? Should Dries put another survey out?
Comments
I would rather see quality
I would rather see quality vs quantity, never could understand the rush to the next version, its like all the CMS on the web are competing to get that next release in, instead of focusing on one quality release.
Quality meaning, on a scale of 1-10, it's an 8 or 9 before even attempting a new release.
The issues with many of the CMS are usually the exact same due to too many releases in the oven and module chaos, trying to cook the bird before you add the stuffing. What happens when you have too much food in the oven, it doesn't all get cooked and the end user suffers.
I don't believe it is so much about how often a release should be, but how to simply and effectively manage just one release and then only when needed give it an upgrade like very six months. Where is the rule that says there has to be a new release.
5.7 is not even complete and people are talking about 7. sounds Joomlaish if you ask me.
I like the idea of after having a quality piece of work then taking 1 year to give it a nice upgrade it gives module makers time to upgrade their modules so that by the time the release comes out, all the modules are ready to go.
An upgrade or new release is the sweet dessert everyone looks forward too, how many got excited about 6.0 only to find they can't even use it because there are no spoons (modules). DOH!!!
Drupal should learn by its mistakes and those from the other CMS, new releases, upgrades, modules, all this should be quality managed, open source should have more quality, especially since there are many quality people involved in the project but instead all people are worried about is writing code and getting the next beta (half baked turkey) released.
Quality is coming up
Drupal 7 is going to be the first release that's had formal usability testing and it'll also be the first release with automated functional and unit test coverage. Those two things, alongside other initiatives to improve QA should make a massive difference this release cycle, whilst also allowing for a much longer real development process due to less bug hunting (I hope).
The usability is already addressing a lot of UI issues (although major improvements were already made between 4.7 and 5, and 5 and 6).
Unit testing might be the beginning of the end of the time lag between core and contrib updates. If module maintainers have tests for their modules set up, they can do a minimal upgrade as soon as the next Drupal version opens then be alerted every time an API their module uses gets broken (as their tests will start coming back false). This is likely to work a lot better than the 'wait 'til beta' or 'wait 'til rc' approach - both in terms of the stability of core as more edge cases get tested earlier, and in terms of timely upgrades. Certainly it'll work a lot better than people complaining in the forums ;)
Not to mention that two major features people want to see in core for D7 are views and cck - those very same modules people are currently complaining aren't ready for D6. Part of getting those modules core worthy for D7 is making sure they're in good shape for D6 - which means they're both getting major API and functionality improvements as we speak - not just a raw, rushed, upgrade.
The main problem here seems to be so many people itchy to upgrade as soon as 6 comes out, when Drupal 5 is going to be supported for at least another year. Who's impatient?
Agreed
As a relatively new Drupal developer -- I think we were at 5.4 when I first started -- I'm finding the transition to 6 a bit jarring. It isn't entirely the Drupal core team's fault that many third-party module developers have not yet caught up, but still I don't think D5 is so terrible that a few more weeks or months in a release candidate form for D6 would have done any harm -- it was notable how quickly 6.1 came out. For the foreseeable future, I will still start new work projects with D5, and only use D6 for a personal site I toy with in my free time (not yet online)…
Stockholders at for-profit corporations like scheduled releases, but that's not something FOSS developers have to deal with most of the time, thankfully. Therefore, let it be done when it's done. If D6 lasts well into the 2010s, it will be no tragedy -- if/when D7 comes out, it'll be all the better, even if it does break module compatibility again.
Clearly , new core , with no modules , is "useless"
Few days before i decided to migrate from Joomla to Drupal and i got to the 'select branch' procedure.
After a BIT of searching through the most popular modules i found out D 6 was clearly Out of the question. (first to mention , the Node Import and User Import modules , required for the migration to happen , weren't ready , following almost every other major module i wanted)
Of course it's not a fault of the core dev team that the maintainers didn't update their code in time (..at all!, considering the 7-month code freeze i read on your topic, thats A LOT of time) , but thats a price we have to pay in order to have non-commercial , GPL based modules. (i still prefer it)
I dont know whats the actual nature of the GPL Licence but HOW ABOUT if you gave the maintainers and module-developpers some Motivation ? I dont know what that could be, but the Drupal Project is becoming bigger and bigger every day so there are things the community could offer to these guys that make our Drupal websites what they are.
I dont have a problem Making major releases LESS OFTEN (D.5 is really excellent at everything) ,but that still doesnt assure us that the modules will be ready.
(excuse my crappy english)
Yea, there was some talk
Yea, there was some talk (somewhere) at the conference about possibly rewarding people for writing documentation (maybe every time someone downloads your pdf you get $1).
Although many developers ask on the project page for support, maybe we should have unified means of promoting the community donating not only to the association but to the module developers. There should be a handbook page (don't know if there is already) specifically talking about supporting the various projects (there's a short page for the association, but nothing about modules and even that one, I think can probably be better/more convincing). It doesn't have to be a whole lot of money...a little from a lot of people can go a very long way.
Would Like to See More Emphasis on 6
I agree that things appear to be a bit rushed. I would rather see much more attention on 6 before 7 is even mentioned.
Tony Valle
Promethius Consulting, LLC
Release schedule
I'm a software developer that has added managing the company website to his other list of chores. I've got a drupal site prototyped to replace the most recent custom written iteration, but would like to go to 6.1 (or wherever it ends up being) before our release. I'm stuck because the module developers can't keep up. Of the 20+ drupal modules that we are using on the 5.x prototype, there's maybe 7 ready now.
I feel drupal should radically alter the way they are managing their software. If you call the strcpy C function, it copies one string to another. Now you may find a new whiz bang approach to doing that which is faster. Great. You substitute the new code in and improve your C library. But the end user calls remain the same. I really don't see any reason that a module that worked in drupal version 1 shouldn't continue to work in version 6. It may work slower because it has to take more steps to create the same result, or it may work faster because drupal's core functionality is better, but it should still work without the module writer having to do a single thing.
If you want to make a new class of functions for version 6 and move most of the code base to that so that you aren't dragging along old code and the slowdowns that they entail - great - prefix every core function with d6 or something and call the release level specific functions wherever you can in the internal drupal core. But make an unchanging and maintained external interface that the module authors can call that doesn't change from release to release so that they don't have anything that needs changed unless they want to add new features to their own modules themselves. Drupal module writers need to discipline themselves to only call these external functions and not rely on any internal call, even if it is faster, so they aren't tied to the release!
The API that exists for drupal release x can be extended for release x+1 and can have new options for existing features and brand new features added without harm. The module writers can choose to use these extensions at the cost of losing the ability to have a module written for release x+1 run on x if they want. If they use them for release x+1, however, they shouldn't have to worry about them breaking in x+2 (or x+99 for that matter). strcpy, to refer back, still does strcpy, even after all these years.
You can't keep having people have to rewrite their code because you want them to now call function X.1 with this set of arguments instead of X with a different set of arguments from now on to do a particular thing. Many will say - well we have that now, essentially. Well, if you do, then why weren't the modules released at the same time as drupal and why can't you successfully take any module that worked on 5.x and have it work on 6.x? It might not have all the features the module writer wants to make available in his or her version 6 module, but why doesn't it just work with the 5.x functionality without problems? This must change. These same things are true for module writers. Develop an API for your module and stick to it. That way we don't have the interconnected problems we have now. Your module should never be holding up another module's development unless you are collaborating and the other module's author is specifically waiting for new features you are providing for the next release of your module. If the author wants to use the API you are providing in your current module release, they shouldn't have to worry about it breaking in your new release.
Figure out what module writers need as functionality, create some stable APIs, and commit to maintaining them as core functionality from now on. Doesn't mean you can't add new stuff. Just don't break the old stuff in doing it. This can be done. It just takes a bit more time and isn't as fun. It's still better code development practice.
Keep things simple and you'll have less buggy code and much happier module writers and users.
Initial Impressions
As a longtime lurker but short time site owner to Drupal (about to upload my first site) the comments below are an initial impression.
I will qualify these comments by saying that I have not heard the Dries keynote or seen the subsequent discussions so have not been influenced by them, and I am aware that being a newcomer there may well be things I am missing.
There does seem to be a dearth of completed modules and a delay in release would probably have improved the situation.
The shorter period of support with the short release schedule must be a factor for clients looking for a stable CMS system to deploy.
I assume the options for change are to increase the timescale for release i.e. to 18 or 24 months or to release as ready.
I do feel that a change is would be beneficial but without more experience I would not like to express an opinion on which would be the best path.
Hopefully this would take pressure off those who work so hard on both core and contributed code.
Off to study this topic in more depth
Dries is launching a commercial version
Interesting post but I think a lot of the concerns you raise might be answered by Dries unveiling plans for Carbon - a commercial version of Drupal.
I raised a discussion topic about that recently. As I understand it, the way the commercial version of Drupal works is that you pay a subscription to Dries' new company to get support for core and contributed modules that have already been rigorously checked by programmers.
Which will be great and while I'm looking forward to seeing what sort of Drupal distributions they will come out with, I'm also slightly disappointed it has to go commercial for that to work.
I like the open source approach, even with donations if a developer is stuck for time or a lot of work is involved to get something working, but to go commercial like this indicates that either the open source approach doesn't work or that the Drupal community simply hasn't been harnessed and managed properly or efficiently.
If the commercial version of Drupal wasn't coming, I would have agreed with the points made on here. In particular the idea of slowing down the frequency of releases - so at least we have stable versions to work with, instead of racing ahead at breakneck speed.
I'm pretty sure the
I'm pretty sure the commercial version of Drupal that will be coming out has...absolutely nothing to do with this topic.
To address an earlier comment, the reason that Drupal 5 modules are not compatible with Drupal 6 modules is that APIs change between versions and backward compatibility is not something that the current Drupal developer mindset cares about. Backward compatibility is extremely complicated, can harm design principles, and creates a lot more hassles. So the Drupal developers chose not to be backward compatible.
The API that exists for drupal release x can be extended for release x+1 and can have new options for existing features and brand new features added without harm.
If you assume the above statement is true, then a lot of interesting things come out of this. However, there is a lot of assumption in that statement. The brand new features added without harm just doesn't hold true. You can't rewrite an entire subsystem, getting rid of outdated logic, without harm. That's part of the point.
I feel drupal should radically alter the way they are managing their software.
Lots of people have opinions. Opinions require no knowledge, insight or even wisdom. Opinions are very, very easy to express. Much, much easier than actually contributing.
For example:
Drupal module writers need to discipline themselves to only call these external functions and not rely on any internal call, even if it is faster, so they aren't tied to the release!
If the author had any actual knowledge of what was going on, then this author probably would not have decided to just call all the module developers lazy and undisciplined. Seriously. If we're so lazy and undisciplined, why are you using our code and not writing your own? If it's so easy and obvious to see that our undisciplined nature is fucking up your site, why the hell are you even here?
All that said, I'm in favor of a longer dev cycle.
I'm also in favor of these threads not filling up with a bunch of "you developers are ignorant idiots" complaints. It's no wonder that developers have a reputation as being mean bastards.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
Yeah, I understand that
Yeah, I understand that attitude completely. I'm one of the non-developers so I'll keep my contribution short and sweet and then get out of the real workers' way! :-)
1. Thanks for a fantastic CMS. I've known Drupal for a year and am still on the learning curve but it's worth every step of the journey.
2. I do feel D6 should have not exactly been kept under the covers, but actively promoted less aggressively until a larger proportion of the "main" modules (I'm talking things like views, cck, image, video, pathauto, newsletter modules, tinymce, buddylist, og, voting modules, etc) were ported to 6. Viewing the "Recent Posts" pages in the last 3 weeks has been an experience in deja vu...."port to 6", "drupal 6 version?", "when ready for 6", etc, etc. That would be my only complaint....and it's more an observation really.
non coder perspective
Points taken, but, from a non coders perspective I can see the commercial version of Drupal becoming the benchmark rather than the community version.
Dries and Acquia can't release a commercial version of Drupal that is buggy, so the focus will be on getting everything to work properly, rather than rushing out a release to keep up with the cms possé.
In other words, the commercial version of Drupal will/should be considered the 'clean' and 'stable' version, which is what developers will prefer to work with and therefore determine release frequency.
That's not a reflection on the Drupal community developers and I don't think anyone is calling them ignorant or idiots...it's more a project management issue. i.e. harnessing the drupal developer community and striking a balance between innovation and stability simply hasn't been achieved. If it was, there would be no need for the commercial version of Drupal.
phil
Acquia is likely to depend
Acquia is likely to depend heavily on the popular contributed modules that people are waiting for, not to mention core.
If it was a fork, then suggesting it'll become the 'clean and stable' version might make a little sense (even if it was wrong). However it's going to be in Acquia's interests to ensure that the contrib modules they depend on are well maintained, have bugs fixed quickly, are kept up to date with major release versions etc. - i.e. that core, and the 'core modules that aren't in core' remain the benchmarks.
So Drupal core is going remain innovating, and as far as I can see on a one year release cycle (more or less), but I think we're likely to see about 30-100 contrib modules that end up with larger teams working on them (and more financial support for the developers in one way or another) - which is likely where the division will really be.
Updates
I agree with some of your points. I'm not a drupal developer - although I have tweaked some modules to address issues we had, but I do develop software for a living.
I in no way think the developers are "ignorant idiots" and if I came across sounding that way, I apologize. What I do think is that a lot of the module developers seem to be overwhelmed. The time delay in addressing bugs for version x due to time commitments needed to get their modules ready for version x+1 and delays in getting x+1 modules out the door makes this clear. That has to change for drupal to survive and grow. Addressing the "backward compatibility is not something that the current Drupal developer mindset cares about" is important in the long term.
The software I develop is in the real time process control system field - a lot of assembly code and C. It has included complete C cross-compilers, assemblers and linkers in the early days, microprocessor simulators, multitasking operating systems, and much oil and water field related process control and monitoring software, along with associated data base and communication system work. All of the projects are large in terms of code size. The software has to work pretty much right the first time and keep working forever. If you add something, you can't break anything else. I've been doing that for a very long time. So my mindset is perhaps different from your typical web developer. You'll just have to cut me some slack.
That said, at some point any software package including software for the rapidly changing web should have been developed long enough to stabilize. If it doesn't, then too many people will give up on it in the long run. It just won't be worth the module developer's time any more to keep reinventing the wheel every 6 months because core decided to do things a different way. It certainly won't be worth any end-user (who perhaps must tweak a particular module to get it to work like they want) to have to redo that operation every 6-8 months for no other reason than security patches are going to be unavailable for the release you have in production in a short amount of time. Maintenance is a real issue that this "backward compatibility" mindset hurts.
I think that drupal is basically a pretty good package that produces fairly good website layouts. That's why I chose it. I very much appreciate the module writers. You really need many of the modules to do anything in the corporate environment. I don't want to see module developers give up on drupal due to the apparently large and continuing changes in core.
I still hold with my basic premise. APIs need to stabilize.
In the early days, there may well have been the need to make some drastic under the hood changes that would break an API from release x to x+1. At some point, though, the core developers should get a firm handle on what works and what doesn't, and be able to say we're going to do process X (user identification, access control, node layout, hierarchy, etcetera) this way from now on, fix an API and stick with it. These are the database fields and tables we need to do that. The values may have more enumerations at some point, but the database architecture of these particular tables work and we won't need to change their structure anymore. We might add new tables to handle new and unforeseen data types - we might even add a couple new fields to existing tables - but the fields we have defined now do what we need and are going to stay constant. We're going to do general markup this way and theme developers can insert their changes this way and module developers can get at the data streams this way for tweaking and cast these methods in stone.
Menus are going to be handled this way - we may allow other mark up changes, but it won't affect menus that are out there. Images are going to be handled this way. Flash is going to be handled this way. At some point, you've added enough new things you hadn't fully thought through in version 0.x to 6.x (menus, images, books, nodes, flash, etcetera) that the format for handling the next new wonder web technology just means defining a new table or setting a new node type. Old modules may not understand a new node type of X, but an upgrade shouldn't break things since an update for security shouldn't have any of the new stuff present in the database anyway. If core decides to add other database fields to do a particular function, then that really shouldn't break everything else. It should still be transparent to the outside of core world. Maybe PHP isn't that flexible - I'm personally more used to Perl which I know is.
Again, I apologize if I hurt some feelers. My 8c (adjusted for inflation) from a long time in the real world.
I'm not sure I agree with
I'm not sure I agree with the idea of standardizing the API. I am a firm believer in the saying "the only thing constant is change" (Murphy's law of computer programming: any given program, when running, is obsolete), PHP itself is changing and evolving. Developers are being given tools they didn't have in the past, which allows them to things they couldn't do before or simplify things they did do. We will never get to the point where we can say "all that can be done is" (remember those guys back in the day who said everything that can be invented, has been invented?
So naturally, Drupal will continue to change as the tools made available to us change (that is, if we want to get to and remain on the cutting edge). Dries, in his keynote spoke about moving away from the "node" (which is sort of the basis of how Drupal works now) system and going towards "fields"...well you can watch it here: http://sgluskin.podomatic.com/entry/2008-03-03T15_51_59-08_00 to get an idea of where the project is going.
The problem is just how fast we do that...
Look at commercial entities
I think that a 12 month cycle is a bit too fast. I have a hard enough time keeping up with updates. If you look at commercial developers like Adobe, they have a longer timeline. Adobe is about 18-24 months if I remember correctly. Microsoft (depending on product) can be several years also.
Drupal seems to work pretty well in v5 and v6 has some really nice features. But to get to the masses, they need much better UI and one-button upgrades. These things take time on stable systems.
And Ubuntu has six months...
And Ubuntu has six months...
again, motivate the module developpers
Can't stress this enough. Modules are the force that moves Drupal (thats why i came here for) . The developpers are doing something really great and valuable (worst quality modules in Joomla are being Sold / commercial licenced! ) so we really really should focus on rewarding them for their offer, they could have a percentage of the Donations for example.
(someone mentioned a commercial - Drupal ? Well if that's true then i should really start worrying. Wouldn't be good news for the open-source-community. I dont want to emphasize on this offtopic-issue but if the Drupal team wants to have financial benefits from the Project, this could be done in an efficient-indirect way. )
Motivating module developers
There's a few ways you can do this right now.
1. Donate money directly to module maintainers.
Some of them have links on their project pages, nearly all have a contact tab. You won't see third parties collecting money to donate to module developers, that causes all kinds of issues, but no one's going to bite your nose off for offering them money (well, not many people anyway).
2. Adopt an issue queue.
People often complain how long it takes for some maintainers to fix bug and support requests on their queues. This supposes that maintainers don't have day jobs, kids etc. of their own. Even if they work on Drupal full time, there's very few who get paid to maintain modules (and even then rarely full time). If you use a module regularly, it's likely that you're quite capable of answering, 20, 40, even 90% of support requests posted in the issue queue - so why not jump in and answer them? Again, as long as you make an effort to answer the question, no one's going to complain. While you're there, you can test patches that fix known bugs, verify if reported bugs exist etc. etc. - every minute you spend doing this saves time for someone else - often the person who's upgrading your favourite module to D6.
hm
1. i dont think that would work. we need something more organized.
2. personally, i ll answer everytime i can
It is true
See:
http://acquia.com/
It's not a 'commercial
It's not a 'commercial version of Drupal' - it's going to be distributions of Drupal with commercial support and upgrade stuff. So it'll be the same Drupal core, and most likely popular modules selected from contrib, with some custom code glueing bits together and additional infrastructure to support it (or something like that, there's no release yet). It's also pretty likely that any changes which acquia makes to Drupal core and contrib (which anyone can, and does do) will get contributed back to the project as patches - given that the project lead and CTO are the same person :)
Conceptually I'd say it's pretty similar to the difference between Debian and Ubuntu.
yep. it is a commercial version..
To quote the Acquia website:
For all intents and purposes, a commercial supported distribution of Drupal = a commercial version of Drupal.
As I understand it, 'Carbon' has a paid full time team of programmers (a few of the core developers of Drupal are now full time employees of Acquia and working on Carbon) which means companies/individuals have the option of paying for the Carbon distribution and support or downloading the Drupal.org distribution for free.
Let's face it, cleaner code, less bugs and support is Carbons unique selling point. It's not difficult to imagine, therefore, that module developers might prefer to work with Carbon (the commercial distribution of Drupal,) rather than the free Drupal.org version of Drupal, because the code will be cleaner and it will have less bugs. It will be easier to update etc.
I think that's a good thing...particularly for people like me who are non-programmers that know a little bit of php and find it difficult to deal with all the bugs that crop up in the free Drupal.org version of Drupal.
However, I can also see the other side of the coin: i.e. will we end up with a fork where some of the developers prefer to work with the commercial version and others prefer to work with the free Drupal.org version?
It's unclear how the royalties system will work for Carbon, i.e. if you contributed a module/significant amount of patches for a module that is included in the commercial distribution of Drupal, how much will you make in royalties?
ditto for support/testing/submitting patches etc. Will people prefer to submit patches to the commercial version of Drupal and make some money or will they prefer to test/submit patches for the free drupal.org version?
As I say, it's unclear how the royalties system for develoeprs/.support/patchers/testers will work with Carbon, but, I can see the benefits of going that way.
..
One can say
apple == orangeall day long but that doesn't make it true.--keith
understood..
I understand what you're trying to say Keith, but, Carbon is essentially a commercial version of Drupal.
There's a clear distinction between commercially supporting a Drupal distribution that is based on Drupal 6 with a few contributed modules and launching a new version of Drupal called Carbon...which will be based on Drupal 6 with a few contributed modules.
If what you're insinuating is true..why launch a new version of Drupal? Why not just contribute to the free version of Drupal and commercially support a distribution?
my earlier point was just pointing out the obvious: Carbon will be geared towards commercial, enterprise and social publishing and therefore the majority of Drupal developers might prefer to develop using Carbon, rather than the free Drupal.org version..despite patches from Carbon eventually finding their way back into the free drupal.org version.
That approach might help the long term stability of releases....which I think is what the original poster alluded to.
There's a clear distinction
It is my understanding that what Acquia is doing with Carbon is pretty much what you've said in the first part of your sentence here. I think they are "commercially supporting a Drupal distribution that is based on Drupal 6 with a few contributed modules". I think they happen to have a pet name for it because like most of us, they think code names are cool.
I'm not really trying to insinuate anything, I don't think they're launching a new version, and I think they've said publicly they're going to very actively contribute to the "free version". I really suspect that they'll do what all of us do when we need a change in core or a contributed module: they'll engineer a change, contribute a patch back to the appropriate issue queue, and argue coherently for its commitment, while, if necessary, managing their patches upstream to keep their platform stable for their customers. That's the same thing I do if I *have* to make a change in something; that's what I think they'll do as well.
--keith
BTW, anyone who is reading
BTW, anyone who is reading this thread with a sense of deja vu...
http://drupal.org/node/132496
that was the thread that was all the rage when I first joined drupal.org
as they say, the more things change, the more they stay the same. I await next year's one with great eagerness...
Also...
I'm thinking it's beginning to sound like this one: http://drupal.org/node/202638
--keith
I'm thinking it's beginning
Funny thing. I was thinking about Democracy and Linux for Drupal too before i read this topic.......
the santa thread
LOL! I was thinking of that thread while reading this one. They should be tagged as 'santa' threads...i.e. they always come around once a year.
A Customer/Developer Insite
We currently have 8 seperate web applications which I have asked to make recommendations on how to consolidate them into one system/interface. Additionally I was asked to make a recommendation on how to standardize development so that any department could hire a contract development team or direct internal personnel to develop applications for the provided platform. The consolidated system must be upgradeble to keep pace with the OS and hardware. Oh, and it must be cost effective and not require high cost maintenance and licensing models. They're not asking for much, are they? :-)
Currently one is written in .asp and being updated to .net. The second is being developed on Cold Fusion 7, it is the final stages of core development. The other 6 have been developed in the BMC Remedy Action Request System. Three very distinct technologies which can be made to work together but not seamlessly.
It took me all of about 10 seconds to think "Modular capable CMS". I have not at this point ruled out any CMSs in favor of any other. Ultimately I have to look at the following criteria:
-> Long term stability and the ability
-> CMS must be able to be kept current with security updates
-> Some type of support, either community or commercial but it has to be there and be cost effective.
-> It must have a well documented module development interface to the core functionality
-> Strict and enforcable account security and group controls
Drupal has just about all of these capabilities, but the one thing that could keep me from recommending it would be the yearly version updates requiring rewrites of the modules. We will not be able to develop the inhouse modules that we need, and then rewrite them every year because of core changes. Every two years would be pushing it but we could probably justify it in the name of functionality and security.
Are we canidates for the commercial version of Drupal? It would depend on inital release time, delivered core functionality and the reassurance that the core API would remain stable for longer periods of time. The quick core version turn over with modular rewrites required for each would not work for us, and would problably count against Drupal as the CMS base of choice.
On the personal side I'm sticking with Drupal 5 and probably won't consider updating to 6 or 7 until all of the modules I use are updated. The version that the modules are developed for first will determine which I upgrade to. Personally, if I were actively developing a Drupal module I wouldn't consider version 6, but would start working on version 7. I wouldn't be suprised if some of the module developers are already thinking this. Why develop for a version which already has an end life date? Spend the time maintaining the current version and work towards rewriting for the next big release. Maybe version 6 is doomed to a half life because of version 7 already being discussed.
well, drupal 6 was already
well, drupal 6 was already being discussed when 5 was released at the start of the year: it's the way things are done around here. 7 won't be out until end of the year/start of next, by which time 6 will be the stable fully-supported version that 5 is at the moment.
..
I'm not so sure if that is a key issue, I think it may have more to do with the fact that medium-to-large scale sites that take months to develop aren't easy to update, particularly when there are big leaps in core API from version to version. Upgrading those sites isn't a straightforward task. It can take a long time and cost a lot of money, so the only upgrades that happen are modular security updates, for example.
When you consider it's probably the same developers of medium-to-large scale sites that are driving contributed module development, it becomes more tricky than just an "end life date" question.
As I understand it, the commercially supported version of Drupal hasn't been finalised yet.
Can I recommend you register at Acquia.com? The initial release of Carbon is being decided based on suggestions from the community. There are more details across at the acquia.com site, but, in brief, you can propose your preferred wish-list of modules to be included in the distribution.
Every two years would be
There is no requirement that your site must be compatible with each version of Drupal, in the order that they are released. As things work now, two versions are supported at any one time. Currently, that is 5 and 6. When 7 is released , that will be 6 and 7. Regardless, any one version has a lifetime that spans multiple years. If you need to manage upgrades in two year increments, just do that, and if necessary, skip a version and go on to the next.
--keith
Most compatible
Few weeks back i was engaged fighting with joomla, though it provides lots of features but as per user friendly CMS i dound Drupal to be the best one. Its site administration system is outstanding. Though i couldnt find any plugins available for SEO or any other purposes, but still the usability of Drupal is much better. Thanx
=-=
SEO = clean urls which is in core
and if necessary the nodewords.module
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )