Drupal 5 incremental release?
You said the current 5.x-dev breaks with contributed modules. But you don't see a reason not to release it?!
It's been quite common that contributed modules have required some updating along with the Drupal core upgrades (even the incremental ones). If there is a new policy which says that a Drupal core upgrade should never result in any contributed modules being broken, that seems like a new precedent. Many people will welcome the backwards compatibility, but I it seems like a lofty goal given the many changes to the codebase and/or database.
On Saturday 21 July 2007 20:08:57 Caleb Gilbert wrote:
You said the current 5.x-dev breaks with contributed modules. But you don't see a reason not to release it?!
It's been quite common that contributed modules have required some
updating along with the Drupal core upgrades (even the incremental ones). If there is a new policy which says that a Drupal core upgrade should never result in any contributed modules being broken, that seems like a new precedent.
It depends on the meaning of the word "upgrade". Upgrade should probably stand for 5.x -> 6, whereas update 5.x -> 5.y, where x < y. In the latter case, yes, no modules should ever be broken. That's the meaning of the API freeze in the first place. -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name
Vasileios Lourdas wrote:
On Saturday 21 July 2007 20:08:57 Caleb Gilbert wrote:
You said the current 5.x-dev breaks with contributed modules. But you don't see a reason not to release it?!
It's been quite common that contributed modules have required some updating along with the Drupal core upgrades (even the incremental ones). If there is a new policy which says that a Drupal core upgrade should never result in any contributed modules being broken, that seems like a new precedent.
It depends on the meaning of the word "upgrade". Upgrade should probably stand for 5.x -> 6, whereas update 5.x -> 5.y, where x < y. In the latter case, yes, no modules should ever be broken. That's the meaning of the API freeze in the first place.
Unfortunately, we have in the past had to fix bugs in such a way that caused contrib modules to break. This happened in one of the later 4.7 updates.
On Saturday 21 July 2007, Vasileios Lourdas wrote:
On Saturday 21 July 2007 20:08:57 Caleb Gilbert wrote:
You said the current 5.x-dev breaks with contributed modules. But you don't see a reason not to release it?!
It's been quite common that contributed modules have required some
updating along with the Drupal core upgrades (even the incremental ones). If there is a new policy which says that a Drupal core upgrade should never result in any contributed modules being broken, that seems like a new precedent.
It depends on the meaning of the word "upgrade". Upgrade should probably stand for 5.x -> 6, whereas update 5.x -> 5.y, where x < y. In the latter case, yes, no modules should ever be broken. That's the meaning of the API freeze in the first place.
As I understand it, the policy for intra-version upgrades (5.x->5.y, etc.) has been "don't break anything unless you really really really have to for security" (e.g., swapping out an XML-RPC library mid-version.) I think that's a good policy to maintain. I don't know enough about the supposed 5.x-dev breaks to say if they count, but I am running 5.x-dev on a site that just launched because I needed some of its bugfixes, and so far nothing has blown up. It's even survived an upgrade to jQuery 1.1.3.1. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Larry Garfield wrote:
I don't know enough about the supposed 5.x-dev breaks to say if they count, but I am running 5.x-dev on a site that just launched because I needed some of its bugfixes, and so far nothing has blown up. It's even survived an upgrade to jQuery 1.1.3.1. :-)
Likewise -- we installed and tested 5.x-dev from on or about July 15 for DrupalEd -- we tested it pretty thoroughly in a few different hosted environments with views, cck, og, and some other contrib modules, and all ran well -- wrt the "need" for a point release, I don't see it as that pressing an issue -- I think there's a lot to be said that the project has been able to go for the last six months without a security issue in core -- Now here's hoping I didn't jinx nuthin :) Cheers, Bill -- Bill Fitzgerald http://www.funnymonkey.com Tools for Teachers 503.897.7160
On 7/21/07, Larry Garfield <larry@garfieldtech.com> wrote:
On Saturday 21 July 2007, Vasileios Lourdas wrote:
On Saturday 21 July 2007 20:08:57 Caleb Gilbert wrote:
You said the current 5.x-dev breaks with contributed modules. But you don't see a reason not to release it?!
It's been quite common that contributed modules have required some
updating along with the Drupal core upgrades (even the incremental ones). If there is a new policy which says that a Drupal core upgrade should never result in any contributed modules being broken, that seems like a new precedent.
It depends on the meaning of the word "upgrade". Upgrade should probably stand for 5.x -> 6, whereas update 5.x -> 5.y, where x < y. In the latter case, yes, no modules should ever be broken. That's the meaning of the API freeze in the first place.
As I understand it, the policy for intra-version upgrades (5.x->5.y, etc.) has been "don't break anything unless you really really really have to for security" (e.g., swapping out an XML-RPC library mid-version.) I think that's a good policy to maintain.
Yes, that is the policy. API fixes, such as http://drupal.org/node/135926, are sometimes okay as well, after a bit of scrutiny.
I don't know enough about the supposed 5.x-dev breaks to say if they count, but I am running 5.x-dev on a site that just launched because I needed some of its bugfixes, and so far nothing has blown up. It's even survived an upgrade to jQuery 1.1.3.1. :-)
I am running any sites which I can, including a live clients' site or two, on 5.x. -- Neil Drumm http://delocalizedham.com
Quoting Caleb Gilbert <caleb.gilbert@gmail.com>:
You said the current 5.x-dev breaks with contributed modules. But you don't see a reason not to release it?!
It's been quite common that contributed modules have required some updating along with the Drupal core upgrades (even the incremental ones). If there is a new policy which says that a Drupal core upgrade should never result in any contributed modules being broken, that seems like a new precedent. Many people will welcome the backwards compatibility, but I it seems like a lofty goal given the many changes to the codebase and/or database.
That may be true for Drupal but as I understand from an industry standard POV incremental upgrades should never change the API. If a module has created a workaround for a bug that becomes fixed is one thing. For a module to break merely because of an incremental upgrade seems a bit over anxious to include new functionality in core. Earnie
Earnie Boyd wrote:
For a module to break merely because of an incremental upgrade seems a bit over anxious to include new functionality in core. Sometimes it's been necessary (or at least pragmatic) to change an API to fix a bug, usually security related. That's all that's been said.
Personally I'm running 5.x-dev because of bugs in 5.1... As for an update breaking contrib modules - isn't that why we have release candidates? I know normally those are reserved for major releases, but in this case might it not be wise to have a 5.2-RC ? -- Adrian Simmons (aka adrinux) <http://perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On 7/23/07, Adrian Simmons <adrinux@perlucida.com> wrote:
Earnie Boyd wrote:
For a module to break merely because of an incremental upgrade seems a bit over anxious to include new functionality in core. Sometimes it's been necessary (or at least pragmatic) to change an API to fix a bug, usually security related. That's all that's been said.
Personally I'm running 5.x-dev because of bugs in 5.1...
As for an update breaking contrib modules - isn't that why we have release candidates? I know normally those are reserved for major releases, but in this case might it not be wise to have a 5.2-RC ?
As far as I know, we don't have any precedent for doing a release candidate on a stable branch; this would be a new policy and the release infrastructure might not be set up to handle it. We can not control the release schedule of security issues, Drupal gets released as soon as a satisfactory fix is well-tested by the security team, the stable branches could already be considered release candidates. The current 5.x will get released when needed. I am not aware of any modules breaking in 5.x, other than this issue Darren Oh has raised. -- Neil Drumm http://delocalizedham.com
On Jul 23, 2007, at 2:57 PM, Neil Drumm wrote:
As far as I know, we don't have any precedent for doing a release candidate on a stable branch;
Agreed.
this would be a new policy
True.
and the release infrastructure might not be set up to handle it.
Not a problem at all. The release infrastructure handles this case all the time in contrib land (e.g. views 5.x-1.6-beta5 etc, and then finally the views 5.x-1.6 official release). update_status.module version 5.x-2.* (and therefore, update.module in D6 core) even handles this case nicely, by not telling you your site is out of date and nagging you to upgrade until the official release comes out, though it will inform you that the "Latest release" is whatever the most current release is (e.g. a 5.2-RC of core). Cheers, -Derek
On Monday 23 July 2007, Neil Drumm wrote:
As far as I know, we don't have any precedent for doing a release candidate on a stable branch; this would be a new policy and the release infrastructure might not be set up to handle it.
We can not control the release schedule of security issues, Drupal gets released as soon as a satisfactory fix is well-tested by the security team, the stable branches could already be considered release candidates. The current 5.x will get released when needed.
I am not aware of any modules breaking in 5.x, other than this issue Darren Oh has raised.
I think the question is the definition of "when needed". There's no major security hole that needs plugging AFAIK, which is the usual impetus, but does "a crap load of bug fixes" count as "needed"? Personally I'd say yes, especially as some of those enable functionality (e.g., fixing a form submit handler so that it plays nice with overrides). If people are running 5.x-dev in production without problems now that sounds like acceptable regression testing. It's been six months. That's an eternity in Drupalcom. :-) (I'd actually support maintenance releases on a schedule, and it would make my boss the business nut happier, too.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 24 Jul 2007, at 04:10, Larry Garfield wrote:
I am not aware of any modules breaking in 5.x, other than this issue Darren Oh has raised.
I think the question is the definition of "when needed". There's no major security hole that needs plugging AFAIK, which is the usual impetus, but does "a crap load of bug fixes" count as "needed"? Personally I'd say yes, especially as some of those enable functionality (e.g., fixing a form submit handler so that it plays nice with overrides). If people are running 5.x-dev in production without problems now that sounds like acceptable regression testing. It's been six months. That's an eternity in Drupalcom. :-)
I think it's about time that we make a Drupal 5.2 release available -- there might have been more than a hundred bugs fixed. So Neil, by all means, go for it! :) -- Dries Buytaert :: http://www.buytaert.net/
If we release 5.2 now, we will break sites that use SSL. In 5.x-dev, there is a bug such that there are separate session cookies when a site is accessed via https versus http. See the 6.x issue queue here: http://drupal.org/node/160107 I know Neil is already aware of the issue, but I thought I would point it out to others. NOTE: this is not a bug fix for 5.1. It is a critical bug that was introduced after 5.1 and should be fixed before we break sites with a premature 5.2. But after that critical bug is patched, I'm in favor of a 5.2 release. - John On Jul 24, 2007, at 2:55 AM, Dries Buytaert wrote:
On 24 Jul 2007, at 04:10, Larry Garfield wrote:
I am not aware of any modules breaking in 5.x, other than this issue Darren Oh has raised.
I think the question is the definition of "when needed". There's no major security hole that needs plugging AFAIK, which is the usual impetus, but does "a crap load of bug fixes" count as "needed"? Personally I'd say yes, especially as some of those enable functionality (e.g., fixing a form submit handler so that it plays nice with overrides). If people are running 5.x-dev in production without problems now that sounds like acceptable regression testing. It's been six months. That's an eternity in Drupalcom. :-)
I think it's about time that we make a Drupal 5.2 release available -- there might have been more than a hundred bugs fixed. So Neil, by all means, go for it! :)
-- Dries Buytaert :: http://www.buytaert.net/
participants (11)
-
Adrian Simmons -
Bill Fitzgerald -
Caleb Gilbert -
Derek Wright -
Dries Buytaert -
Earl Miles -
Earnie Boyd -
John Wilkins -
Larry Garfield -
Neil Drumm -
Vasileios Lourdas