Drupal 5.2 and 4.7.7 released
Killes and I have released Drupal 5.2 and 4.7.7. These are bugfix and security releases; upgrading is strongly recommended. Further details are at http://drupal.org/drupal-5.2 The CVS tags are DRUPAL-5-2 and DRUPAL-4-7-7 The direct downloads are http://ftp.drupal.org/files/projects/drupal-5.2.tar.gz http://ftp.drupal.org/files/projects/drupal-4.7.7.tar.gz Thanks goes to the security team, everyone who reported and reviewed security issues, and everyone who worked on bugs. -- Neil Drumm http://delocalizedham.com
On 7/26/07, Neil Drumm <drumm@delocalizedham.com> wrote:
Killes and I have released Drupal 5.2 and 4.7.7. These are bugfix and security releases; upgrading is strongly recommended.
Further details are at http://drupal.org/drupal-5.2
This seems a good place for a clarification. (I would post it in "support" but then it would probably be answered by someone like myself) In the 5.2+4.7.7 announcement, in the "Upgrades" section, it says: "For the most trouble-free transition from an existing installation, it is recommended that you first upgrade to Drupal 4.7.6 or Drupal 5.1." In the 5.1+4.7.6 announcement, it was:: "For the most trouble-free transition from an existing installation, it is recommended that you first upgrade to Drupal 4.7.5 or Drupal 5.0." What is the purpose of this? (Not recommending to go straight to 5.1 when it was released, but recommending it now that 5.2 has been released.) Is it a safety valve in case something upgrade-related has been overlooked in the new release? Or does it mean that one has to follow the chain and trace back all the minor releases one by one?
The CVS tags are DRUPAL-5-2 and DRUPAL-4-7-7
The direct downloads are http://ftp.drupal.org/files/projects/drupal-5.2.tar.gz http://ftp.drupal.org/files/projects/drupal-4.7.7.tar.gz
Thanks goes to the security team, everyone who reported and reviewed security issues, and everyone who worked on bugs.
-- Neil Drumm http://delocalizedham.com
Quoting Cog Rusty <cog.rusty@gmail.com>:
On 7/26/07, Neil Drumm <drumm@delocalizedham.com> wrote:
Killes and I have released Drupal 5.2 and 4.7.7. These are bugfix and security releases; upgrading is strongly recommended.
Further details are at http://drupal.org/drupal-5.2
This seems a good place for a clarification. (I would post it in "support" but then it would probably be answered by someone like myself)
In the 5.2+4.7.7 announcement, in the "Upgrades" section, it says: "For the most trouble-free transition from an existing installation, it is recommended that you first upgrade to Drupal 4.7.6 or Drupal 5.1."
In the 5.1+4.7.6 announcement, it was:: "For the most trouble-free transition from an existing installation, it is recommended that you first upgrade to Drupal 4.7.5 or Drupal 5.0."
What is the purpose of this? (Not recommending to go straight to 5.1 when it was released, but recommending it now that 5.2 has been released.) Is it a safety valve in case something upgrade-related has been overlooked in the new release?
Or does it mean that one has to follow the chain and trace back all the minor releases one by one?
Good questions, I would also like to ask why upgrade.php should not handle a straight 4.x to 5.2? Isn't it designed to prevent the need to do incremental upgrades so that all of the needed upgrades are self contained? Earnie
Earnie Boyd wrote:
What is the purpose of this? (Not recommending to go straight to 5.1 when it was released, but recommending it now that 5.2 has been released.) Is it a safety valve in case something upgrade-related has been overlooked in the new release?
Or does it mean that one has to follow the chain and trace back all the minor releases one by one?
Good questions, I would also like to ask why upgrade.php should not handle a straight 4.x to 5.2? Isn't it designed to prevent the need to do incremental upgrades so that all of the needed upgrades are self contained?
Well, update.php does not include older updates, so if one has an older 4.x site (let's say 4.5 or 4.4), he cannot upgrade directly, but first go to an intermediate version. I have not looked into it, but update.php might have problems, or would not inform the user, if he has such an old system that has no updates in the actual update.php/update.inc/*.install files code. Previously the numbers were linear, so if you had a system updated to version 12, and you could only run updates from 17 through 32, then the missing 13-16 updates would result in a corrupted system. Now the numbers are not linear, there are version jumps, so telling if you miss updates is harder. Who knows if there were 600x updates after the 6008 update you have done last on your site or not? That said, it would be great to test and document from what version can people upgrade to a particular Drupal version, and and document that instead of suggesting intermediary updates for all cases. Gabor
On 7/27/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Earnie Boyd wrote:
What is the purpose of this? (Not recommending to go straight to 5.1 when it was released, but recommending it now that 5.2 has been released.) Is it a safety valve in case something upgrade-related has been overlooked in the new release?
Or does it mean that one has to follow the chain and trace back all the minor releases one by one?
Good questions, I would also like to ask why upgrade.php should not handle a straight 4.x to 5.2? Isn't it designed to prevent the need to do incremental upgrades so that all of the needed upgrades are self contained?
Well, update.php does not include older updates, so if one has an older 4.x site (let's say 4.5 or 4.4), he cannot upgrade directly, but first go to an intermediate version. I have not looked into it, but update.php might have problems, or would not inform the user, if he has such an old system that has no updates in the actual update.php/update.inc/*.install files code.
The question remains, because how would it help to upgrade such an old version first to 5.1 and not to 5.2? An advice which seemed safe so far was (a) never skip major versions (b) when stepping to the next major version use its latest minor version, assuming that it would be more "bug-fixed" People seem to have been doing that successfully. So, it surprised me to see a suggestion to go first to the second-newest minor version every time..
Previously the numbers were linear, so if you had a system updated to version 12, and you could only run updates from 17 through 32, then the missing 13-16 updates would result in a corrupted system. Now the numbers are not linear, there are version jumps, so telling if you miss updates is harder. Who knows if there were 600x updates after the 6008 update you have done last on your site or not?
That said, it would be great to test and document from what version can people upgrade to a particular Drupal version, and and document that instead of suggesting intermediary updates for all cases.
Gabor
Cog Rusty wrote:
Well, update.php does not include older updates, so if one has an older 4.x site (let's say 4.5 or 4.4), he cannot upgrade directly, but first go to an intermediate version. I have not looked into it, but update.php might have problems, or would not inform the user, if he has such an old system that has no updates in the actual update.php/update.inc/*.install files code.
The question remains, because how would it help to upgrade such an old version first to 5.1 and not to 5.2?
An advice which seemed safe so far was (a) never skip major versions (b) when stepping to the next major version use its latest minor version, assuming that it would be more "bug-fixed"
Absolutely agreed.
People seem to have been doing that successfully. So, it surprised me to see a suggestion to go first to the second-newest minor version every time..
IMHO these are copy-pastes, and it is a good idea to discuss them. Gabor
On 7/27/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Cog Rusty wrote:
Well, update.php does not include older updates, so if one has an older 4.x site (let's say 4.5 or 4.4), he cannot upgrade directly, but first go to an intermediate version. I have not looked into it, but update.php might have problems, or would not inform the user, if he has such an old system that has no updates in the actual update.php/update.inc/*.install files code.
The question remains, because how would it help to upgrade such an old version first to 5.1 and not to 5.2?
An advice which seemed safe so far was (a) never skip major versions (b) when stepping to the next major version use its latest minor version, assuming that it would be more "bug-fixed"
Absolutely agreed.
People seem to have been doing that successfully. So, it surprised me to see a suggestion to go first to the second-newest minor version every time..
IMHO these are copy-pastes, and it is a good idea to discuss them.
When I first saw in the previous announcement of 5.1+4.7.6 the suggestion to go to 5.0 first, I also thought that it was an oversight with a copy/paste. But then I noticed in the announcement of 5.2+4.7.7 that it was updated to "go to 5.1 first" and I wondered if there was a reason.
Gabor
On 7/27/07, Cog Rusty <cog.rusty@gmail.com> wrote:
On 7/27/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Cog Rusty wrote:
Well, update.php does not include older updates, so if one has an older 4.x site (let's say 4.5 or 4.4), he cannot upgrade directly, but first go to an intermediate version. I have not looked into it, but update.php might have problems, or would not inform the user, if he has such an old system that has no updates in the actual update.php/update.inc/*.install files code.
The question remains, because how would it help to upgrade such an old version first to 5.1 and not to 5.2?
An advice which seemed safe so far was (a) never skip major versions (b) when stepping to the next major version use its latest minor version, assuming that it would be more "bug-fixed"
Absolutely agreed.
People seem to have been doing that successfully. So, it surprised me to see a suggestion to go first to the second-newest minor version every time..
IMHO these are copy-pastes, and it is a good idea to discuss them.
When I first saw in the previous announcement of 5.1+4.7.6 the suggestion to go to 5.0 first, I also thought that it was an oversight with a copy/paste. But then I noticed in the announcement of 5.2+4.7.7 that it was updated to "go to 5.1 first" and I wondered if there was a reason.
The next sentence in the "Upgrading" section of the announcement:also has a problem, I think: http://drupal.org/drupal-5.2 quote:"If you are upgrading from Drupal 4.6.x or below, please consult the relevant release announcements." I don't understand. We are now reading the 5.2+4.7.7 announcement. Which are the "relevant release announcements" for upgrading from 4.6.x? (And if there is such a thing, where).
On 7/28/07, Cog Rusty <cog.rusty@gmail.com> wrote:
On 7/27/07, Cog Rusty <cog.rusty@gmail.com> wrote:
On 7/27/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Cog Rusty wrote:
Well, update.php does not include older updates, so if one has an older 4.x site (let's say 4.5 or 4.4), he cannot upgrade directly, but first go to an intermediate version. I have not looked into it, but update.php might have problems, or would not inform the user, if he has such an old system that has no updates in the actual update.php/update.inc/*.install files code.
The question remains, because how would it help to upgrade such an old version first to 5.1 and not to 5.2?
An advice which seemed safe so far was (a) never skip major versions (b) when stepping to the next major version use its latest minor version, assuming that it would be more "bug-fixed"
Absolutely agreed.
People seem to have been doing that successfully. So, it surprised me to see a suggestion to go first to the second-newest minor version every time..
IMHO these are copy-pastes, and it is a good idea to discuss them.
When I first saw in the previous announcement of 5.1+4.7.6 the suggestion to go to 5.0 first, I also thought that it was an oversight with a copy/paste. But then I noticed in the announcement of 5.2+4.7.7 that it was updated to "go to 5.1 first" and I wondered if there was a reason.
The next sentence in the "Upgrading" section of the announcement:also has a problem, I think:
http://drupal.org/drupal-5.2 quote:"If you are upgrading from Drupal 4.6.x or below, please consult the relevant release announcements."
I don't understand. We are now reading the 5.2+4.7.7 announcement. Which are the "relevant release announcements" for upgrading from 4.6.x? (And if there is such a thing, where).
To understand these upgrade instructions I tried to trace their origin (also looking for points where utility becomes ritual). Two old announcements by Dries seem relevant, 4.5.0 and 4.5.2.
From 4.5.0 quote: "For the most trouble free transition, it is recommended that you first upgrade existing installations to Drupal 4.4 and only then to Drupal 4.5."
No problem here, these are major versions.
From 4.5.2 quote: "For the most trouble free transition from an existing installation, it is recommended that you first upgrade to Drupal 4.5.0 or Drupal 4.5.1"
This "or" makes things clearer: "Don't trust this new release *yet* with major version upgrades." I guess this is what has been carried over to the recent announcement. Are there still good reasons for this caution? Because I see many people in the forum for whom an additional upload and minor update is also a real risk.
From 4.5.2 again quote: "If you are upgrading from Drupal 4.4.x or below, please consult the Drupal 4.5.0 release announcement [a link] for more information."
This seems to mean: "If you are upgrading from an older major version (4.4.x), then consult the first release announcement of this major version (4.5.0) because you will find more upgrade info there." So, the "relevant announcements" in our case should be 5.0, 4.7.0, 4.6.0,... (provided that there are actually more upgrade information there)
Cog Rusty wrote:
To understand these upgrade instructions I tried to trace their origin (also looking for points where utility becomes ritual). Two old announcements by Dries seem relevant, 4.5.0 and 4.5.2.
From 4.5.0 quote: "For the most trouble free transition, it is recommended that you first upgrade existing installations to Drupal 4.4 and only then to Drupal 4.5."
No problem here, these are major versions.
From 4.5.2 quote: "For the most trouble free transition from an existing installation, it is recommended that you first upgrade to Drupal 4.5.0 or Drupal 4.5.1"
This "or" makes things clearer: "Don't trust this new release *yet* with major version upgrades." I guess this is what has been carried over to the recent announcement. Are there still good reasons for this caution? Because I see many people in the forum for whom an additional upload and minor update is also a real risk.
This might have been the intention, but I don't think this stands anymore.
From 4.5.2 again quote: "If you are upgrading from Drupal 4.4.x or below, please consult the Drupal 4.5.0 release announcement [a link] for more information."
This seems to mean: "If you are upgrading from an older major version (4.4.x), then consult the first release announcement of this major version (4.5.0) because you will find more upgrade info there."
So, the "relevant announcements" in our case should be 5.0, 4.7.0, 4.6.0,... (provided that there are actually more upgrade information there)
Yes, it makes sense to look at the major version announcement first for information, but IMHO upgrading to that first and then to the latest point release is not practical, neither desired. Gabor
On 7/27/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Cog Rusty wrote:
Well, update.php does not include older updates, so if one has an older 4.x site (let's say 4.5 or 4.4), he cannot upgrade directly, but first go to an intermediate version. I have not looked into it, but update.php might have problems, or would not inform the user, if he has such an old system that has no updates in the actual update.php/update.inc/*.install files code.
The question remains, because how would it help to upgrade such an old version first to 5.1 and not to 5.2?
An advice which seemed safe so far was (a) never skip major versions (b) when stepping to the next major version use its latest minor version, assuming that it would be more "bug-fixed"
Absolutely agreed.
Theoretically, 4.0 straight up to 5.2 in one go should work. All the upgrade scripts are in 5.2. However, changes do sometimes break old updates. Updates aren't especially tested for this since most core developers go straight out of the older versions and stop giving much thought to them. -- Neil Drumm http://delocalizedham.com
On 7/27/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Cog Rusty wrote:
Well, update.php does not include older updates, so if one has an older 4.x site (let's say 4.5 or 4.4), he cannot upgrade directly, but first go to an intermediate version. I have not looked into it, but update.php might have problems, or would not inform the user, if he has such an old system that has no updates in the actual update.php /update.inc/*.install files code.
The question remains, because how would it help to upgrade such an old version first to 5.1 and not to 5.2?
An advice which seemed safe so far was (a) never skip major versions (b) when stepping to the next major version use its latest minor version, assuming that it would be more "bug-fixed"
Absolutely agreed.
Just to add in: I upgraded a few sites from 4.6 to 5.1. One had no issues at all. The other had some issues mainly related to data set size (database too big) and varbinary/UTF8. But the point is: there was no need to install 4.7 and upgrade from 4.6 to 4.7 first, then install 5.1 and upgrade to that. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
Quoting Neil Drumm <drumm@delocalizedham.com>:
Theoretically, 4.0 straight up to 5.2 in one go should work. All the upgrade scripts are in 5.2. However, changes do sometimes break old updates. Updates aren't especially tested for this since most core developers go straight out of the older versions and stop giving much thought to them.
But if the updates in update.php is sequential ... I suppose the real issue is that current update.php isn't able to determine which updates have been applied from previous versions. I would like to think that at some future point this resolvable. Earnie
On 7/29/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:
But if the updates in update.php is sequential ...
I suppose the real issue is that current update.php isn't able to determine which updates have been applied from previous versions. I would like to think that at some future point this resolvable.
Earnie
I don't think this is an issue - the schema version in the {system} table for any given module corresponds to the highest number update that was previously run. -Peter
Here's the heart of the matter... 1) DB updates are written using the core API of the version they are updating you to. E.g. the 60** updates are all for the 6.x core API. 2) Drupal core's API has been known to change. 3) It's possible that an update to a particular version of core is using a core API function that changed or no longer exists in a future version of core. So, hypothetically, the updates from 4.6.x to 4.7.x might have used some function in 4.7.x core that no longer exists or works the same way in 6.x. If that was true, you couldn't just upgrade directly from 4.6.x to 6.x, since when you hit the update function that only worked in 4.7.x core, it would fail and then the rest of the upgrade path could be busted. Therefore, first upgrading from 4.6.x to 4.7.x, then from 4.7.x to 5.x, and finally from 5.x to 6.x, is the safest, since you're always running update functions against the version of core they were written for and tested with. Upgrading from 4.7.0 to 4.7.1 to ... to 4.7.7 is silly and wasteful. To the extent the docs and release announcements give that impression, we should fix them. Of course, 99% of all update functions only use a tiny fraction of the core API, namely the DB abstraction layer. The DB layer doesn't tend to change much, so usually "skipping" some core versions when upgrading isn't much of a problem. However, look at schema API new in 6.x -- for now, it's a non- destructive change, meaning that update_sql() or db_query() still work as usual. But, it's certainly possible that, e.g. in 7.x, schema API changes in such a way that update_sql() no longer works as it once did, or no longer exists. If that happens, it'll be important for sites to first upgrade all the way to the latest 6.x release of core, run update.php, upgrade core to 7.x, and run update.php again. Also, note that update_sql() has been causing bugs and driving me and other developers nuts for ages, since it doesn't provide the same placeholder escaping/substitution functionality that db_query() does, even though lots of people assume it does. :( I never got around to mounting a crusade around that for 6.x, but maybe I'll find time/ energy to do so for 7.x (if schema API doesn't totally change update_sql() by then, anyway). So, it's in fact quite likely that *something* about the API we use for update.php will change in 7.x, and that means upgrading directly from 4.7.x or 5.x to 7.x might not work. If that happens, we should definitely document it clearly in numerous spots, but otherwise, I think the boiler-plate text we've been cutting and pasting in release announcements is probably misleading and should be either removed or clarified based on this info. Cheers, -Derek (dww)
Derek Wright wrote:
So, hypothetically, the updates from 4.6.x to 4.7.x might have used some function in 4.7.x core that no longer exists or works the same way in 6.x. If that was true, you couldn't just upgrade directly from 4.6.x to 6.x, since when you hit the update function that only worked in 4.7.x core, it would fail and then the rest of the upgrade path could be busted. Therefore, first upgrading from 4.6.x to 4.7.x, then from 4.7.x to 5.x, and finally from 5.x to 6.x, is the safest, since you're always running update functions against the version of core they were written for and tested with.
There was exactly a node types API problem with updates from Drupal 4.6 to 5.0 going directly: http://drupal.hu/english/node/8 Gabor
I have been busy so have not really followed this thread.... But in the past, the biggest reason for consistently recommending people update per version release was that it was the most widely tested method of updating your site. While we get the occasional person saying 'it worked fine' to jump from 4.6 to 5.2 etc, The vast majority of active Drupal users update point releases to a large degree. Therefore while it is certainly 'possible' to jump more that that (And I do generally without ill effect) the lack of lots of testing/feedback make the current recommendations appropriate and responsible. Steven On 8/3/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Derek Wright wrote:
So, hypothetically, the updates from 4.6.x to 4.7.x might have used some function in 4.7.x core that no longer exists or works the same way in 6.x. If that was true, you couldn't just upgrade directly from 4.6.x to 6.x, since when you hit the update function that only worked in 4.7.x core, it would fail and then the rest of the upgrade path could be busted. Therefore, first upgrading from 4.6.x to 4.7.x, then from 4.7.x to 5.x, and finally from 5.x to 6.x, is the safest, since you're always running update functions against the version of core they were written for and tested with.
There was exactly a node types API problem with updates from Drupal 4.6 to 5.0 going directly: http://drupal.hu/english/node/8
Gabor
participants (8)
-
Cog Rusty -
Derek Wright -
Earnie Boyd -
Gabor Hojtsy -
Khalid Baheyeldin -
Neil Drumm -
Peter Wolanin -
Steven Peck