Hi, this might have been debated elsewhere, but I've been musing on it for a while and I couldn't think of an easy way to search for it.
I started a big project in Drupal 5.x at the beginning of the year (very complex, 15,000 page site), and we ended up needing a whole lot of contributed modules to do the job. Fantastic, this is just why drupal is so great, but drupal 5 has been out for a while now, and Drupal 6 is the major version, and even though it's on 6.6, there a quite a few fantastic modules which are only just starting to release 6.x versions. If I started a project now, I would have to think seriously whether it was worth going with 6.x, and hoping that most of the other modules catch up during the building process,or going with 5.x, and hoping you guys would still be supporting security updates for the core for any length of time for the site once it was live!
We'll be looking at 7.x soon (how soon?), with people enthusing about 8.x, but what happens to this huge resource of contributed modules if the core keeps running ahead of the pack? Is this actually happening, or is my view a bit skewed? Is anyone else thinking along these lines?
Comments
=-=
core is always ahead of contrib modules.
Some maintainers keep up with the moving target of the next release some do not. Some maintainers don't port their modules until they have a need to for their sites to move to the next major version that has been released. Of course most maintainers review patches to port their modules to the next major version.
There is no how soon for Drupal 7.x, at the time of this comment there are 283 outstanding bugs 244 of which are listed as critical. Beyond that you may have issues trying to go from D5 - D7 with contribs at one time.
When D7.x is released D5.x is slated for sunset. There was some conversation of extending the lifetime of D5 though I admit to losing track of that discussion and don't believe there was a final decision.
I've read that core continuing to move forward benefits the community as it weeds out contrib modules that aren't maintained. Sort of like a survival of the fittest. Personally I think this is a good way to handle things.
i agree - feels like vista and xp issues, right?
i agree - last winter when d6 was rolling around, everybody was ecstatic - people started putting up sites and of course hounding cck, views and og type module developers saying, "where are you? i can't launch my site without views, or without cck, etc" - and this was in jan/feb with early testing going out in spring/summer, and of course 11 months later views is out, cck is out and so on - and now d7 may be rolling into testing in a matter of months...
so the lesson learned from d6 users (imho, and i think this is accurate) is that when d7 rolls out, do *not* upgrade until all major modules are ready for it - because without views and cck alone there are hundreds of other module developers who won't be willing to invest in test releases - they're waiting for stable parent modules, and this lets loose a flood of dependencies...
of course, i suspect that the dramatic changes between d5 and d6 won't be as major when going from d6 to d7, but i could be all wrong - hoping that drupal doesn't let d5 die on the vine the way d4 is dead on the vine - there are some *huge* sites that are running the equivalent of XP (still) skipping vista altogether and waiting for the all new next version (d7 in this case)...
i'd much rather see tons of core backported into d6 for the next TWO YEARS with a d7 test in late '09 because drupal is getting major press, and acquia is promoting heavy adoption, and if tons of new corporate users come on board and begin investing talent and resources like they have with sugarcrm, linux and other open source projects, they will be very upset if major changes force them to twist and turn every 6 to 12 months - corporations just do *not* operate on those schedules!
...but at any rate, yeah, i agree, the core should continue to evolve but changes should be going into incremental d6 evolutions for now, like a 6.7, 6.8 on through to "6.whatever" for at least a couple of years giving *every* module developer - particularly those with ft jobs elsewhere doing this at night - time to catch up and commit all of the bugs and fixes for both D5 and D6 users (because again,if they play catch up with d7 in 09, you can bet that the issue queues for d5 are going to languish and that will hurt a lotta sites)
could you imagine if oracle changed this much every 12ish months? or windows? or linux? ...now, just *imagine* what these support forums and module issue queues would look like if d7 came out in early '09!!
........................................................................
i love to waste time: http://twitter.com/passingnotes
Yeah, this is my feeling
Yeah, this is my feeling too, drupal is really rising to a level where really big organisations are starting to pick it up, and this can only be good for drupal module coders and drupal site assemblers, as well as web users in general benefiting from the general level of sanity that drupal promotes. But it takes these guys AGES to have all their meetings and consultations, and to build a site which does everything which they want, and the twists and turns of politics on a big project in a large organisation means that you can't feasibly be upgrading cores once a year, it will just turn project management types off drupal. Or if you have to then it means loads of contributed modules will drop off. Please, oh high priests of drupal, keep 6 alive for another two years! It's only just at a stage to start building big projects with it now, and soon it could be on the way out!?
should this be a reason to not use drupal for a big corperate project at all? Drupal 5 is also fantastic at the moment, I love that to get security fixes for quite some time to come... =)
=-=
Corporations and coming on board certainly won't hurt nor do I think they will get put off by core moving forward and leaving behind legacy baggage. Matter of fact it may help as corporate entites will bring developers or money to help developers.
Drupal 6 isn't on the way out, Drupal 6 will be around until Drupal 8 is released as stable. which very well could be 18 - 24 months.
My impression is that those who came at the end of Drupal 5.x were caught off guard by the release and lag time of contributed modules for Drupal 6.x and as such they feel like drupal is releasing every year. This isn't the case and there is a release document around here somewhere that shows the lifetime of each version.
Keep in mind when 4.6 was around and 4.7 there was a different versioning system.
4.7 was a major upgrade to 4.6
Drupal 6.x is mature at this stage and there are more and more releases for 6.x coming out every day. Matter of fact, per my own library at this point D6 is getting more contribution activity than D5. (I sort by date and download each module on a daily basis. I have my own library of modules on my local machine)
It certainly doesn't hurt that the more major modules that make it into acquia releases the quicker those modules will be ported to the next version.
In a land where there are more users of software than developers of software it's just a nature of the beast.
Quite a few modules from Drupal 5.x that haven't been ported to Drupal 6.x aren't needed any longer. Views2 killed off many querrying modules. CCK kills off content type modules and so on. It will always be prudent to do due dilligence when choosing contrib modules for use in a project.
ah, that's true...acquia promotes some serious stability...
having (finally) our own 'redhat' for drupal (in the form of acquia, replete with funding), ensures that major modules will always have serious support - my only concern is the publish-or-perish situation that's going to come about for "all of the other modules" over the coming years - and while that may be a good thing in the long haul, it's going to hurt a *lot* of sites that were built with these modules and for whom there is no simple migration path to new modules (e.g. image and imagefield are both wel supported and provide migration paths, but what about the other great ones that died on the vine, like img_filter?)
........................................................................
i love to waste time: http://twitter.com/passingnotes
=-=
If i remember correctly, img_filter died because of the contributor duplicating code, duplicating modules and the contributor himself using self multilation to try and delete the project, project page and issue and not because of drupal moving forward.
i know, that was just an example...
there are many others simply seeking sponsorship so that these folks can continue work on something that people want - even if it's 20 users, there should be a general attitude that "if it matters to the community, then it should stay alive" - for some it's sponsorship to cover time, for others it's a search for collaborators and contributors...
that particular module had solve some of the inline imagefield handling issues that still aren't solved with the inline api as of today! (yes, i know they're on the map, but not a priority queue item)...but because it died, the efforts were lost, and it did not in fact duplicate everything - it actually integrated what imagefield, image titles and inline were doing in one simple tool with few (if any) dependencies, really a shame that it croaked!
........................................................................
i love to waste time: http://twitter.com/passingnotes
my 2 cents ... 15,000 pages
my 2 cents ...
15,000 pages is not the point for selecting between 5.x, 6.x or 7.x.
the main issue is the structure of your site. what features will be used.
feature = module ...
I believe this is true : 6.x core is better then the 5.x core.
but if u cant find the 6.x versions of those extra modules u needed, u will be in BIG trouble.
How big? depends on your budget.
If u have enough budget, u may get those extra module 6.x ready.
Views and CCK are more than a simple port
One thing that affected D6 is the fact that Views and CCK are much more than a simple port from what they were in D5, which is IMO the major cause of this delay in contrib modules. It might happen again, though.
Doubt is the beginning, not the end of wisdom.
you know what would be nice?
what i'd really appreciate - and many others quite likely - is a definitive statement right on the home page of drupal.org regarding the roadmap to D7 - what it will mean, how it will compare to the D5/D6 transition (meaning is it more complicated or more simple) - what people should begin thinking about now if relevant (database schema, technical architecture - e.g. d7 will require mysql5!) and other pertinent notes...
i know that this information is already floating around, but if you want to find it then you have got to *dig* for it on drupal - and i think it should be right on the home page, up top, like
Latest Release:
-d6
-d7
Contributions:
-modules
-themes
-translations
Future Releases:
-Path to D7 (link to a page with links to all pertinent docs and specs etc)
....right there, on home page, upper right, impossible to miss placement....
........................................................................
i love to waste time: http://twitter.com/passingnotes
See group "improvements to core"
http://groups.drupal.org/improvements-core
Doubt is the beginning, not the end of wisdom.
I think what threw a lot of
I think what threw a lot of us 5.x crowd was the delay between release of 6.x and the release of absolutely critical modules for it. Barring a simple forum/blog site, most of us needed modules that were months and months arriving. All this time, 6.x was being promoted off the front page and the main download page which is why the forum between february and the summer was FULL of "where's my module?" and "port to 6??" posts...there are still a ton of them in the issue queues but the views/cck ports have helped a ton.
Personally, I'm on 5.x still and will probably jump straight to 7.x, even though I know that will be a pain and probably expensive as I have about 25 contrib modules on my site....and a complicated customized theme. If I stick with 5.x, how long will I be able to do that for while the rest of the world is on 8.x and 9.x?? It will become impossible. I've seen 4.7 users getting yelled at on here if they try to get support..."you dinosaur! upgrade!" :-))
Can you imagine me showing up asking for support for my 5.x site when the latest release is 8.7? Ouch....
Hey, I'm with ya! It's good
Hey, I'm with ya! It's good to hear that 6.x will be supported for 18-24 months, it's a little less scary if that's true. When big organisations (and NGOs/Govt Depts don't always have that much spare money) build new websites, they want to put some resources into building a system and once it works they don't want to mess with it for a few years. This may seem a bit backward to the breaking wave of drupal developers (and god bless you as you have done so much good work) but this really is the way a lot of organisations function in my experience, and if we really want drupal to help the wider web as much as it could, being nice to these slow moving peopleoids would help.
The contributed modules are SO much more important than the functionality of the core for me, and 5.x has really built up an alladin's cave of goodies, which it would be a shame to lose. 6.x has obviously sorted out some really important structural issues, and now all I want to do is hit it with a cartoon freeze-ray of some kind and delay the release of drupal7! One of the modules I've found super useful for 5.x is image and all it's buddie modules, and I know you can't take a module in isolation as it's all down to the developer and what's going on in their life, whether anyone is paying them etc, but I just escaped a big 5.x project, and I started to play with 6.x a few weeks ago and I was like "image is still alpha?!" and browsing around, it's the same story for a lot of modules which I've used.
Which is why I'd have to suggest going retro if I was asked to build another big site now and sticking with 5.x, because I know I can do pretty much anything out of the box, copy a lot of stuff I've already done, etc, apart from the fear of a "....sorry, we've given up on five now, no security updates for core, it's all about progress over utility 'round here..." response from the community in a year or so.
It's great to see people sharing on this thread anyway, I don't feel so in the dark anymore!
@thomas - it's a HUGE issue that you've hit on!
when large corporations and organizational users come to drupal, they are going to make the same discovery - many modules for d6 are still beta, dev or alpha or 'rc' candidates of some kind - and so they're going to likely look hard at d5 but will then learn that it's going to be phased out wihtin a couple of years, which may not fit their schedules, and so they may ding drupal altogether (just a hypothetical)
in the larger world of commercial software, most major release linger for 3 to 5 years (yes, 3 to 5) before dropping support for older versioning for this very reason...
........................................................................
i love to waste time: http://twitter.com/passingnotes
.
Commercial software has more resources. We have 1 person in charge of maintaining D5. And a small security team to keep on top of the 4K modules for it. The more versions back we support, the further stretched thin the security gets. And just how long is the D5 maintainer supposed to keep maintaining it? This is already a multiple _year_ commitment for this person. Unpaid, by the way.
There are so many threads like this and they all boil down to the same thing. Lots of people saying what Drupal should be doing with no clear plan on how to make it actually work out that way and often (but not always) the people complaining not jumping in to help, either.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
uh, there are plan suggestions here...
like, "backport core changes for next two years" and so on - but really it's not up to the larger community base, it needs to be put before the core drupal developers - some of core for d7 won't fit into d6, and they'll need to think about attrition within the user base for d5 users who can't make the leap to d6 for at least another year, at which point d7 will more than likely be floating around...
i know that there's a group discussing the future (referenced in this very thread), but what i was looking for was not a group, but rather a super simple absolutely moron-proof crystal clear SHORT statement or summary regarding times and plans like "during X, 2009, we will begin testing d7 and phasing out d5. by X, 2010, d5 will no longer be supported and all d4 will be deprecated. all modules for d6 (will or will not) port (more or less) easily to the new architecture of d7 versus the lengthy transition from d5 to d6. for certain modules there (will or will not) be an upgrade path to d7 directly from d5 (or d6)...etc
........................................................................
i love to waste time: http://twitter.com/passingnotes
.
Suggestions are not a plan. A plan includes providing the resources to carry it out. Who is going to backport core changes? You? That's not being flippant; I'm serious. People keep on saying Drupal should do this and Drupal should do that. Well, Drupal is software. It's the Drupal community that needs to do it. The "core Drupal developers" are everyone who submits or reviews a patch. There is no paid team writing this software. It's done by people who have a need for something to happen and either step up and do it or pay someone to do it.
There is no summary of plans because there are no plans. Drupal has never worked off plans. There are personal battle plans, rough ideas of what people would like to accomplish, but there are no spec documents. You can look to history for some of it. D4.7 stopped being supported when D6 came out. Likely the same thing will happen to D5 when D7 comes out but even that isn't set in stone. If someone qualified steps up to maintain it, then it's up to Dries if he wants to continue support. Contrib is even less certain than core as it's up to thousands of individuals.
People who keep looking for some sort of roadmap and saying that things should be done a certain way just don't seem to get that Drupal isn't built that way. It's all about scratching itches. Your own or your client's. That's how things get done around here. And that doesn't fit into plans and schedules and "shoulds".
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
i hear you, but there *is* a paid team as of this year...
it's called acquia, with drupal core founders commercializing drupal with money from private equity. this means that people are being paid full time to work on improving drupal for a larger audience of both for and non profit installations - and in acquia's case, it also means embracing a handful of major modules that are considered vital to drupal functionality for multiple environments and installation profiles
so as for 'who' is going to backport changes, it's going to likely be those with a vested personal and financial interest in making things work - we've already seen tons of random sponsorships to get work done on modules to make them work, and in the case of acquia, they're doing something amazing by contributing their ongoing improvements back to the community
here's an example of what i'm talking about btw - http://www.linuxfoundation.org/en/LSB_Roadmap
or this: http://struts.apache.org/roadmap.html
or this: http://www.jboss.org/community/docs/DOC-10740
...and *not* this: http://drupal.org/node/46638
maybe a better way to approach this kind of problem/challenge is to consider the development of a resource like this within: http://association.drupal.org/
?
........................................................................
i love to waste time: http://twitter.com/passingnotes
=-=
I doubt a roadmap like what you are asking for will ever be put into existance. I make this assumption because I too have seen this same exact discussion albeit in different threads at least 3 times per new release in my years of working with drupal. I just don't think it is that simple, if it were, that time line would be presented already.
Even though Acquia is involved the manpower of Drupal versus the manpower in those others that you mention isn't quite equal as far as I know. Who can say for sure how long it will take to fix the 286 pending bugs? on D7? Backporting changes from D7 to D5 may be problematic too as D7 will drop PHP4 and MySQL4 support. Which I see as a great "feature". I won't have to carry PHP4 baggage in core when I am not using PHP4.
Maybe I'm missing some of the discussions but from those that I've read it's seems like its users with limited skillsets and in some cases users who have no desire to acquire even a small portion of a skillset, who seem to be having a more difficult time with core progressing forward than it is developers of contributed modules. Or those who come in toward the tail end of a release and don't want to wait to use the next major release. I also tend to disagree with the idea that the speed at which core is being advanced will somehow stunt it's growth.
Drupal may just need more resources. Manpower more than money in the cases of contrib modules I'd think. Acquia is part of the answer but certainly not all of the answer.
Ideally I envision corporations adopting Drupal & ultimately hiring coders who will also contribute back to the community the same way Acquia does.
While these discussions usually get quite a bit of traffic and "me too" commenting. I think it would be awesome to see the same effort being extended to helping those contrib modules that you want ported or ported more quickly, or partially ported by those same people. While all contribution are welcome in the community, what drupal needs more of is people doing some heavy lifting and getting their hands a little dirty.
As PHP evolves so does drupal. As PHP gets easier to work with so will Drupal.
More and more tools are being coded and made available. Are they 100% effective right now? no, but they sure do help and in time will continually get better.
Tools that will allow users to test and check whether they should even consider a certain contrib module regardless of the feature set it provides are better areas for these resources I spoke of earlier.
i agree, like module statistics alone is a giant leap forward
i was thrilled when stats were made public because for years, no joke, i often selected some modules by reading the commentary and commits and feedback from several core drupal figures (i won't name names here) - the idea being that if person X was involved in core *and* working on a small handful of modules then that module was quite likely important to 'very heavy contributors'
the same potential exists for corporate usage - and in one dream it's like some giant media companies putting on drupal folks like yahoo with hadoop or ibm with linux or sun with openoffice and so on...that would be outstanding..
and yeah, acquia is quite a bit smaller, but i'm thinking more like 5 years out, not right now, which is when i suspect that without a roadmap some corporations won't even be allowed to look at drupal - budgets are crazy tight right now, IT spending is going to plummet for the next 18-24 months, companies are already laying of development staff across all markets and sectors, so the case for 'saving serious money and offering something awesome' by investing in drupal as a 'business case' goes far beyond 'look who else is using it' (that used to work, that whole kind of case/logic)...
........................................................................
i love to waste time: http://twitter.com/passingnotes
acquia
Acquia will continue to make many contributions to the Drupal project as we solve issues for our customers and do our best to fulfill our mission of bringing the power of social publishing to everyone. But no one has asked Acquia to formalize a community hierarchy and implement the kind of structured engineering and decision-making processes that would be required to produce a reliable Drupal roadmap or to effectively coordinate more timely module ports. Acquia is a citizen, not a mayor.
Dries decides what gets into Drupal core, but he has little to no control over what code is produced and how fast it is written. Dries sets thematic release goals, but these are not ironclad because a) virtual all the developers are volunteers with their own priorities and b) there is no formal process or methodology for distilling the goals in to manageable chunks of work that are committed to be completed in a specific period of time.
Remember that there is no real Drupal engineering team team or process in the conventional sense. There is no product manager doing market analysis or customer interviews or writing and prioritizing user stories in a well-maintained product backlog. There are no scrum teams, sprint backlog, sprint schedule, daily scrum meetings, burn down charts, end of sprint demo meetings, and there are no scrum masters. There are no product tasting meetings with customers, no sprint retrospectives, etc.
All of the things described above exist in conventional engineering teams to provide efficiency, predictability, and agility in the development process. And that makes it possible to have a real product roadmap. But the Drupal project is not a conventional engineering team. Whether such a methodology could be applied to the Drupal project is an interesting thought experiment that perhaps we should be asking ourselves as a community. But one thing is clear, changing the way the project functions would be a community decision, not an Acquia decision. The project is all of us, not one person or one company.
Jeff Whatcott
Acquia
jeff, thanks for such a thoughtful reply..
seriously, thank you. i think that the citizen versus mayor analogy is spot on- and a good way to look at it...and a larger issue to contend with is that even if acquia were to put forth such a figure (e.g. a product manager to drive initiatives), there is still great potential for tension - look at what happened with mysql when monty&co wanted to focus on speed while major corporate users were focusing on security issues (this was several years ago)...and this happened back in 90 with bsd when the camps formed (in fact, what happened with jolitz, bostic, hubbard, mccusick and co was specifically related to 'openining up the OS' versus 'making it good for corporate use' - a very relevant fight) - yes, i'm a treasuretrove of worthless historical knowledge in some of these areas...and i certainly would NOT want to see 'drupal camps' form!
perhaps fundraising through a central foundation could make this kind of thing possible? is such an idea practical or palatable? a company-neutral, market/application-neutral, 'faith-neutral' central entity charged with soliciting feedback through well designed and implemented surveys and feedback sessions designed to effect roadmap shaping and 'future of drupal' communications to the larger audience? at some point, it's just got to get easier for everybody to get their arms around this kind of stuff...
........................................................................
i love to waste time: http://twitter.com/passingnotes
=-=
Fairly easy to figure out. check out the project page of each release 4.6 4.7 5.0 6.0
Drupal 7
I don't know yet when Drupal 7 will be released, but part of my job as project lead is to make sure it is not too soon but not too late either. To do so, I listen to the community (as always), I look at the competitive landscape, and I listen to my own gut feeling. As for my own gut feeling, it has no desire to release Drupal 7 unless Drupal 6 got significant traction.