Yesterday at Drupal Downunder, the question of product life cycle came up during the Q&A at the end of Dries' Keynote.

Traditionally Drupal supports the current version, and the previous version. When a new version comes out the oldest supported version is retired. This is great, except the unpredictable life cycle means that clients investing in Drupal sites cannot be certain of the amount of time before their site will have to be upgraded, and in some cases the support period for each major version number is not long enough (from a client perspective).

Take Drupal 6 for example. It's been 3 years between Drupal 6 and Drupal 7. Let's say the next 3 Major releases are 18 months apart each. While Drupal 6 will have enjoyed a 4.5 year period, Drupal 7 will only gets a 3 year run before the site owner will have to invest to stay up to date.

What if each Drupal release had a minium lifetime support guarantee? This gives the client confidence that the site they are investing in will be supported for at least a defined period of time.


nirbhasa’s picture

Thats actually not a bad idea. At the very least, a defined end date for support (even if it is shorter than some of us would like) would definitely allow for long term planning.

One link i came across a couple of days ago: These guys backported D5/6 security flaws for 4.x, but only for core modules they themselves used.

But it got me thinking - I wonder if a consortium of interested parties could be found to each 'scratch their own itch' and offer to contribute backported patches for vulnerabilites in core modules they are using? Then hopefully the job could be less of a drag on people. Of course, you would still need someone to coordinate and commit.

(My $0.02 on how long it should be - aside from the Drupal version, websites do have a finite lifecycle of 4-5 years before they begin to look a little dated, or need to be upgraded to take advantage of the latest web developments. When I tell my clients about the major upgrade work required in a few years, many of them shrug and tell me the site is going to need upgrading anyway :) Is an LTS guarantee of 4 or 5 years possible?)

edit: forgot to finish some sentences

_gramur’s picture

I think it is just as efficient to stay a version behind the current. Meaning having a site run on Drupal 6 now that Drupal 7 is released. When Drupal 8 is released then upgrade to Drupal 7 etc. A major release every 18 months isn't likely based on previous release schedules.

However if a major release were to be every 18 months apart I think a better system should/would be in place to ensure client confidence. Imagine having a Drupal 8, 9 and 10 version all released and provide support for Drupal 6 & 7. Would it be that necessary?

Michael Phipps’s picture

3 years IS a long time, and you're right - having to support all those versions of Drupal would not be a good use of developer time, and it would not encourage people to upgrade to later versions (which I think is very important).

So, like you say, it really does come down to a more concrete release cycle that can be planned for.

Jaypan’s picture

I've read some complaints that Drupal 7 took three years to come out. I personally feel the opposite though for the exact reasons posted in this thread - just updating the few modules I maintain is about a month long project, and I haven't even started on any of my sites yet. For a client, an upgrade to the newest version is a significant expenditure with a likely loss of functionality initially (due to modules that aren't ported). This is not an ideal situation for clients at all.

Michael Phipps’s picture

Yeah, updating modules takes time. I think the key is to be working on upgrading D6 modules to D7 now that it has just been released (or even in the lead up), and not when D6 is retired. At least, that's the plan I'm working to.

I think a set release cycle would help plan that work ahead of time, and include it in contracts, so that clients are aware if they do not upgrade that security updates will not continue.

Jaypan’s picture

My own modules aren't the problem. It's the contributed modules - that's where the functionality is going to be lost. And the cost to the client - hundreds of dollars on the smallest sites, thousands on larger, is off putting.

A Drunken Theory’s picture

Agreed. I'm working on my first Drupal site and I've started developing in D7. Much of the functionality I require is provided by D6 modules so I am either forced to wait, develop them myself, or start over and start on D6.

Since I am new to Drupal, learning the complex API or the core and all the modules has been time consuming to say the least. I haven't even grasped what exactly I need to create a module after 3 weeks of consistent reading. Most of my problems is that most of the "default" documentation is written for D6 so I really have no idea where to start with D7.

So now I'm faced with the decision to develop in D6, however, I'm nervous that once I understand Drupal enough to be comfortable with developing my own modules, will D6 be fully depreciated or will it be on it's way out (kind of like it is now.)

Right now, my project with Drupal is at a complete standstill and I've even considered just dumping Drupal all together and finding or developing a viable solution to fit my needs. I originally went with Drupal for several reasons but it was mostly the community and the community contributed modules, but now I'm finding it's not as "knitted" as I would like it to be. There's a complete lack of documentation for Drupal 7 and it is very very very very frustrating for absolute new comers to the system like myself. It seems many of the D6 community developers haven't fully embraced D7 because I'm assuming they've been developing on D6 and have gotten their sites where the want them and there's no need for D7 for most current developers.

Jaypan’s picture

It's really worth investing in a book when a new release comes out. As you say, there isn't a lot of documentation out there, but a book will give you a comprehensive breakdown. I bought a book when D6 came out, and I bought another when D7 came out (2 actually), and they were well worth the money. I've upgraded all my contributed modules to D7 now, and I couldn't have done that without having made the investment.

Michael Phipps’s picture

My module development got much easier when I had a reference book to refer to.

A Drunken Theory’s picture

Can you recommend which ones helped you the most please?

Jaypan’s picture

Drupal 6:
Learning Drupal 6 Module Development: This book was great. It works on the process of teaching through example (which is how I learn best). Each chapter in this book is dedicated to developing different modules, explaining what is happening in the code as it progresses. If you learn by example and analysis of that example, this book is great.
Pro Drupal Development Second Edition: I haven't actually used this book, but many people swear by it. However, I used the D7 version (see below), and I would imagine that the D6 version is written in a similar style.

Drupal 7:
Drupal 7 Module Development: This is the Drupal 7 version of the first book listed above. This book is similar to the D6 version in that it goes through and teaches through example, examining the code as it goes. Very good explanations.
Pro Drupal 7 Development: I found this book good to use having come from a fairly complete understanding of Drupal 6. However, if I were to be new to Drupal in D7, I probably would find the other D7 book listed above preferable, as I found this book to be better for reference, rather than example. There are examples through the book, but they are not analyzed in great depth, and it seems that to some degree a pre-existing understanding of Drupal and what is going on is, if not necessary, then definitely beneficial. But as a reference, this book is very comprehensive and goes over many parts of Drupal with a lot of information on them.

WorldFallz’s picture

definitely-- those 2 books are worth their weight in gold. both of them.

A Drunken Theory’s picture

I ordered Drupal 7 Module Development. Thanks for the advice.

esllou’s picture

I think 90% of the complaints would go away if they just agreed to support one more version.

so when D8 comes out, continue supporting D6 and let it drop off the radar when D9 comes out.

you'll then move to a position where major versions are being supported for another year or so.

WorldFallz’s picture

exactly who is they? Are you volunteering?

esllou’s picture

that's a central policy. Somebody decided in the last five years "we'll support one version back and no more". I don't remember that being put to a vote on the forum. That same person or those near to that person (we all know EXACTLY which 4, 5, 6 people we're talking about here...) could equally decide "ok, let's now support one further back". Clear?

WorldFallz’s picture

that's what i thought. As usual, those whining loudest about what everyone else is doing for the community for free are unwilling to actually do anything themselves. They just wax on about what everyone who's else should be doing.

As stated in the other thread on this topic any one or group of users is free to pickup the support for any version of drupal they like. But as usual, once challenged, those that complain loudest don't actually consider it important enough to justify their expenditure of free time and effort.

Sorry, but that leaves your argument with zero legitimacy.

esllou’s picture

did you read a single word of my reply? It has NOTHING to do with people volunteering. It's a SET, CENTRAL policy. Go and ask Dries why it's so. Maybe he'd answer "because we don't have enough man hours, enough volunteers to support 2 old versions." Maybe he would. But it has zero to do with individuals "volunteering time" on this or any other forum. I can't change this policy because, as I say, it was never put to a vote here. Rather like the parroted "it's core" answer we see on here, "it's just like that" is usually the response when people ask why older versions are not supported for longer.

It's a set, central Drupal policy to support only one old version. A policy established by very few people at some point along its timeline, perhaps right at the beginning. My suggestion is that, in the click of a button, the click of some keyboard keys, that policy can be altered. It probably won't be and there are very strong arguments for saying it shouldn't be, but that doesn't mean it's written indelibly in stone either.

WorldFallz’s picture

You simply don't get it. All the policies in the world are meaningless if there's no one to implement them. The policy exists the way it does precisely because of the resources that would be required to expand it to include more versions. Dries could change the 'policy' tomorrow-- and in the other thread, said he would be willing to do so-- that does not magically produce the resources required to implement that policy.

you can bluster on all you want trying obfuscate the fact that while you are willing to tell every one else how they should spend their volunteer time to better support you, you yourself are unwilling to do anything about it. No one is fooled. Invariably when I see people complaining about drupal not doing this or that, and click on the tracker of the one complaining, they've contributed nothing.

Those that want something done and are willing to put their money where their mouth is do so-- those that aren't willing to put their money where their mouth is whine in the forums.

esllou’s picture

and on drupal rolls.

esllou’s picture

this is a good read on the issue:

I'll say what I said in another post on this thread: I'm not convinced there is any need to alter the policy but two quick new versions (in say, three years total) and a lot of users are going to feel abandoned. A lot already do even though D7 took three years.

Final words: I think the policy is basically OK, it's implementation and "tone" could do with a tweak.

Heine’s picture

*Every* new release there's a lot of wailing and gnashing of teeth about the dropped support for a previous version.

I've never seen anyone really following through on supporting such an older version. The only conclusion I can draw from this is that, all things considered, it is not important enough.

I'm not entirely certain it is different this time, but if so, is there to get some community organization. Dries has already stated that he's willing to keep committing contributed patches to D5.

edit: this is going a bit offtopic.

The main feature of the proposal is changing saying "supported for an unknown amount of time" to "supported for X years". That could even mean support is dropped on D7 _before_ D9 is out.

esllou’s picture

I think "supported for X years" is not ideal. A whole lot can happen in X years. X years could mean 3 new main versions...or none.

that's why I think if there was to be a change (and no certainty that it's needed), it's neater just to add a one to the number of previous versions that are supported.

backwards compatibility has always been a red flag issue on these forums. Sure, people could then ask for 3 old versions to be supported, but I feel 2 is a good compromise.

Heine’s picture

Why not 4 or 5 versions?

esllou’s picture

ah, the good old "slippery slope" argument, used by campaigners against marijuana legislation since Jesus smoked his first bong.

I've never read of people asking for 4 or 5 versions to be supported. 2? Yes, plenty of times.

Heine’s picture

I'm not making an argument, just asking.

Jaypan’s picture

It amounts to the same thing here.

esllou’s picture

well, as I say nobody is asking for 4 or 5 and it would mean supporting old versions for ten years - totally impractical as I think 99% of people would agree.

doing an upgrade from drupal 5 to drupal 9? That would be one interesting afternoon :o)

I don't think the policy will change. If D7 had come out 12-18 months ago as it was scheduled to, there would have been more of a call to keep D5 on the map. But D7 took ages and it looks like it will be another good while before a fully stable version of it will be ready to carry live sites.

Jaypan’s picture

If there is that much 'gnashing of teeth', it probably means that it's a pretty big issue. Just because people don't follow through on it doesn't mean they don't want to, it's just not an easy thing to do when the central source ( isn't backing up that support of it. It's not like these people all of a sudden just think to themselves 'well I grumbled, but now everything is ok. I don't actually want to support it anyways'. It's just a matter of not being in a position to do so effectively.

Heine’s picture

I also don't see people seeking a position to do so effectively. drupal-lts is the home of tumbleweeds. Conclusion, the ROI on Dx support is not high enough for businesses. It is much cheaper to backport patches for yourself (see openflows).

Also, what does d.o. has to do with support for D5? In the simplest case, simply grab the code from CVS and setup

(and now for something completely different: people, fix your input formats!)