There will always be security releases to older versions, which provide an opportunity to roll in some other fixes (not new features). For instance there is a severe problem that prevents 4.6 working with MySQL 5.12+ and ISPs are converting to it. Since 4.7 is not even in beta yet this is a show stopper. It also has problems on the CVS of a few days ago - I don't know about current CVS. IBM used to have (may still have) an issue escalation process that declared some problems as "Severity 1" which put teams on solving it 24x7 until fixed. Most current security bugs in Drupal are treated close to this process. I think there are bugs which deserve a similar high priority, e.g. the MySQL 5.12+ bug.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Nedjo Rogers Sent: Monday, February 27, 2006 11:12 PM To: development@drupal.org Subject: Re: [development] enterprise needs
1) A trivial patch I submitted to the project.module to fix a permission problem in 4.6 wasn't going to be committed (without some prodding) because "4.6 is frozen", even though the code was actually broken (one of the access control permissions didn't work at all if you tried to enable it) and a 1-line change got it working.
Derek, I agree with your general point on 4.6. In the issue you reference, http://drupal.org/node/49408, I didn't mean that 4.6 was (formally) frozen--just that, to my knowledge, no one was doing much active maintenance.
But this small distinction gets fairly near the core of the issues we're discussing. The situation is that a lot of (paid, economically significant) work depends on volunteer contributions--from Dries on down to module maintainers.
The thing about volunteers is that you can't really require them to do work. They'll contribute largely what they want to, what interests and motivates them. Generally speaking, when there's limited time available, doing maintenance on old releases is often going to rate relatively low when measured up against, e.g., getting an innovative new version out.
So maybe the question really becomes: how do we enable those who depend on old releases to contribute to maintaining them?
Maybe Dries' welcome approach of having a 'release maintainer' is worth looking at here for more than core. Major users of modues could adopt old releases when the module author/maintainer no longer wishes to maintain them.