Well, it's been nearly two weeks since the release of the 4.3.0 codeset. I've eagerly tested a new install just to check out the new features, code functionality, etc... All in all, I like what I see in 4.3.0. I want to upgrade...
Unfortunately, supporting modules and themes seem to be lacking waaaay behind the power curve. Taking a rough count of modules on the download pages - just over 1/4 of them have been ported to 4.3.0, looking at the themes ZERO have been ported (or at least reported as working in 4.3.0 - I know they are *supposed* to just work) - but the download pages don't reflect that they do work with 4.3.0.
I'm curious what the general read is on this. Personally, I feel that a code release shouldn't happen until at **least** 50% of modules and themes (and preferably more like 75%) are ported and working correctly. Although some sites may be happy with the core functioning modules, most sites take advantage of some other modules. I understand the nature of community, and it's everyone's efforts that make it work.
I'm also frankly significantly annoyed with the rapidly changing interfaces and structural changes to the core system that breaks modules in the first place. A major train release should have a burned in module interface. 4.x modules should work with 4.x code - period. It would seem the mantra of 'release often' is nothing more than a 'shoot one's self in the foot' methodology.
I enjoy using the latest and greatest - and don't get me wrong - I *greatly* appreciate the hard work and effort that does go into each and every release. But, as a simple end user, I find the constantly shifting nature of what does and doesn't work with what releases to be a major headache and pain. I want to contribute more, but I'm put off by having to constantly recode things to make them work for each release - just keeping my own personal theme up to date with each release - and taking advantage of new features is more work than I need.
So, I'd like to pose this general question to the other Drupal-ites out there:
How do you feel about the constantly shifting code and module requirements?
Comments
I tend to agree with you
I'm not a programmer, but I need Drupal to do the thing I want with my sites.
I like the new release very much. I never upgraded my site to 4.2 because I had work to do, and did not want to spend time debugging. I have upgraded my site to 4.3 however, and I work on making everything work. I would prefer to build the content of the site, the structure etc.
I think that certain key modules (event, project etc) - which are not in the core - should have special attention regarding compatibility with the newest release, and I think they have.
Now that a lot of usability issues have been worked out, and interface and design is being fixed in the cvs, I believe that the plan is to let some of this rest for a while. So maybe we're lucky and our sites will be easier upgradable after the 4.4 release.
We could be lucky :-)
Dropping in from Langemarks Cafe.
No luck
So maybe we're lucky and our sites will be easier upgradable after the 4.4 release.
We just made important theme and menu system improvements; the former breaks all Drupal 4.3.0 themes, the latter all Drupal 4.3.0 modules. Upgrading them is fairly straightforward and a handful of contributed modules, such as the image and project module, have already been updated. Point is that we continue to break (read: improve) things as we see fit.
Now that a lot of usability issues have been worked out, and interface and design is being fixed in the cvs, I believe that the plan is to let some of this rest for a while.
Usability-wise, we aren't their yet so a new round of concrete usability suggestions would be much appreciated (preferably by starting a new forum topic). For what it is worth, a number of usability improvements already hit CVS. Taken from the CHANGELOG in the HEAD branch:
Re: usability
I've been adding bug reports here and there when I see something glaring. I've not delved into re-assessing higher level usability issues with 4.3.0, but I have noticed that there needs to be soem attention paid to usability issues introduced with new features. For example, the number of clicks to accomplish some tasks has increased with the integrated admin module. We're not consistent with breadcrumbs yet, how do we get consistency across all types of page views? I will start a thread to discuss these issues.
That's why
That's why my hope was for AFTER the 4.3 to 4.4 upgrade.
I know the first here will be a bit of a mess, but I actually look forward to it.
4.4 to 4.5 however...
can we hope for some luck there?
Dropping in from Langemarks Cafe.
Well it is true that having a
Well it is true that having a stable system means more comptability, but you often sacrifice advancement. One of the reasons Drupal keeps improving so much is that the main developers are not affraid to make changes to make a better product.
If it was required to maintain backward compatability you would only see real advancement in features through major releases. 4.0, 5.0, 6.0. Where major code changes could be implemented. And each point release would take just as long as it does now because backward compatability would have to be checked everytime.
Hmm?
What I noticed is that they started keeping track of what's actually compliant with each new release -- I already knew most modules wouldn't be before. My standard practice has been to create a backup copy of my site, install it to my own box, then throw each module at it in order to find out which of them I can actually get away with installing. My present site is running a 4.2.0 kludge using modules that still aren't compliant with 4.2.0.
While I've got a CVS version of 4.3.0 running on a different server, I've also got to admit that while it'd be nice to just be able to install the most recent version and everything else the instant it's ready, knowing what will and won't work is saving more hassle than trying to second guess this myself.
On the other hand, more than anything, I find myself hoping that some of the modules -- like Rating, for example, -- actually do end up being brought up to date. I've been checking in periodically to see what is and what isn't, and I notice when stuff gets done, like Style/Polder, for example. Very cool.
Otherwise, no. I hear what you're saying, but in all I still like the new way of doing things better.
Not doing a good job then
Event.module for example uses form_group which only exists in the sandbox right now as some patches. Yet the module is right there on the download page and the Install completely glosses over the fact. Event.module also fails to take into account older php systems and provides no alternative for array_fill() which didn't exist before PHP 4.2
To fix this add in event.module just under the function event_calandar defanition.
if (!function_exists('array_fill')) {
require_once('array_fill.func.php');
}
then create a file in the event directory called array_fill.func.php
with the following text
<?php
// For PHP version < 4.2.0 missing the array_fill function,
// I provide here an alternative. -Philippe
function array_fill($iStart, $iLen, $vValue) {
$aResult = array();
for ($iCount = $iStart; $iCount < $iLen + $iStart; $iCount++) {
$aResult[$iCount] = $vValue;
}
return $aResult;
}
?>
This is alternative function can be seen at php.net
not exactly
form_group()is part of CVS Drupal. if you see form_group() in the 4.3 release of event.module, then that is a bug. Please file a bug against event.module.Same goes for array_fill() requirement. This is a documentation bug. We should say that 4.2 is required, and suggest a workaround for others.
Please help, folks.
I only discovered this
in the last little bit before posting and was quite irritated by it. Hence the content of my message. I just got done with meetings and will be more than happy to file a bug report against event.module and drupal docs or wherver the array_fill issue should be covered. As it stands event.modlue is the only place I see array_fill used.
Constantly changing API
How do you feel about the constantly shifting code and module requirements?
The stated policy of this project is to prefer elegant code over backward compatibility. I agree with this policy. These constantly changing interfaces which annoy Shane and many others are a direct byproduct of this policy. We rip apart fundamental APIs all the time. It is naive to think that you can construct small, elegant interfaces which serve all needs for years into the future. Especially when you cannot predict years into the future.
I suggest gently emailing Contrib module owners about the new release and their tardiness in releasing a guaranteed compatible version.
Backward compatibility
A major train release should have a burned in module interface. 4.x modules should work with 4.x code - period.
Backward compatibility has both drawbacks and advantages. At this point in time we can afford to ignore backward compatibility as I firmly believe that the drawbacks outweight the advantages. Modules and themes just need to be updated.
Prior to the Drupal 4.3.0 release, all interfaces have been frozen for more than four weeks and module/themes maintainers were repeatedly asked to update their code. If a theme or module doesn't get updated and when no one steps forward to take over maintenance, then the module or theme is either superseded or not actively used. In either case, it isn't a great loss. Trust me, modules that people care about will get a new maintainer when orphaned as illustrated by the fact that the most popular modules are fully Drupal 4.3.0 compliant.
I want to contribute more, but I'm put off by having to constantly recode things to make them work for each release - just keeping my own personal theme up to date with each release - and taking advantage of new features is more work than I need.
I might be mistaken but I don't recall any theme system changes between Drupal 4.2.0 and Drupal 4.3.0 ... ?
Newcomer Perspective
As a relatively new Drupal user/developer, I like it but find the rate of breakage intimidating. I'm implementing a project using 4.2, which so far has one custom module (derived from taxonomy_dhtml), a custom theme (derived from Marvin) and a few patches. I'd prefer to update the project with each release, but I don't have the free time or incentive to wade in and debug the path.
Since a high pace of change flows naturally from the stated goals of the project, what's missing (IMO) is adequate developer docs to ease the migration work or even estimate how long it will take. This is especially true for those of us who don't live 24/7 in the Drupalverse :-) I'd be much more comfortable with the amount of change if I had good information about how to handle it; at the moment it seems scattered and incomplete (Obsolete as of what release? Deprecated in favour of what?).
As it stands, I expect I'll continue to install new releases on my evaluation system until a feature appears that is so compelling it justifies what I guess to be the migration effort.
Drupal's development pace coupled with thin migration docs may reverse the old marketing adage that it's cheaper to keep existing customers than acquire new ones - it makes it easier to get new users/developers but harder to keep the existing ones in step.
Cheers
Ken
Contrib vs Core
I personally find the Drupal method very effective. If something is broken, it gets fixed, even if that something is a core API. If you look at the few amount of versions of Drupal between version 1.00 to 4.3.0, it's quite amazing how mature Drupal is today.
The new project module is making life easier for users, but it hasn't been around for long so it needs some time to settle in.
As someone else said, don't be afraid to send a friendly mail to the module maintainer and ask for an update. Or if the changes are small and you have fixed them yourself, send a patch so others can enjoy it.
Putting a module in contrib is a voluntary act: an independent module author puts something in contrib for others to enjoy, but the main Drupal developers have no real obligation towards it. On top of that, if a module contributer only needs one version for him/herself, he/she is not forced to update it either.
In practice, there is a good cooperation between the two (because many contrib authors work on the core too), but you should still keep this separation in mind.
4.3.0 Good enuf for me
I converted my clients site Tigers for Tomorrow to 4.3.0 without any issues. Fortunately, I had not been up very long at 4.2 so I didnt have a lot of content to protect or a lot of customization at the module level.
I have only found bugs (GMT issues) in the Event module so far and that has been discussed in length here already.
I still vote for Drupal over the others (Nuke, PostNuke, PHP Website, Xayara, etc.) for content organization. I'm still looking for a good module to enhance the content creation for novice users similar to PHPWebsite's graphically oriented input forms (their form builder is pretty awesome, too).
Minor version major problems?
I was just going to add that it seems peculiar that a minor version change from 4.2 to 4.3 should break so much contributed code. Is there any sense of backwards compatilibity in Drupal? I've just begun to look at it as an alternative to an ASP.NET portal I've been developing... But this kind of behavior i must say scares me :)
Innovation is more important
I have been around here for some months now, and have also taken over some modules from others. As far as I can see, innovation is more important here, then backward compatibility. Most of the users only use code which is developed in the official CVS repository, and every developer is encouraged to host open source modules there. If some BC breaking code comes in, the core modules are immediately fixed, and the contrib modules follow up shortly.
So you only have some reason to be scared, if you have lots of custom modules or themes you developed yourself and not downloaded from Drupal.org. Then you need to follow the changes made to Drupal (which are documented in the manual BTW), and apply those changes to your code too.
Unfortunately at the expense
Unfortunately at the expense of usability for non developers.
I disagree
Because we want to make Drupal better and more usable we have to break code that isn't good and isn't usable. Keeping backwards compatibiliyt would really tie our hands too much. This project is mostly done in the developers' spare time.
In the end you will get a better product.
--
Drupal services
My Drupal services
None developers will not add
None developers will not add custom codes into Drupal, so there is nothing to worry about. Modules get updated regularly...