Drupal 6.16 release page needs health warnings

I've already added this note to the front page post:

A new includes/lock.inc file is included with this release to support the locking subsystem. This also involved some database changes. To make sure your site continues to function right, running update.php is extremely important. If you deploy using a version control system, make sure to commit lock.inc to your production codebase. Finally, if you run a bytecode cache such as APC, reset the cache to let it reread the changed files.

I'll add more info on the warning appearing in the update. I'd like to have a patch on the PHP 4 compatibility issue so I can link to a suggested fix for users. I suspect it will be a line or two in changes, which we could tell people to apply manually, and hopefully don't need to rush a 6.17.

BTW the issue prompted to add that note at the start was #732064: "Call to undefined function lock_acquire", locale module were people seem to come back with reports that the issue was intermittent.

Added a note in the paragraph (emphasis added to make it more clear for this issue):

A new includes/lock.inc file is included with this release to support the locking subsystem. This also involved some database changes. To make sure your site continues to function right, running update.php is extremely important. Update.php will display warnings of the non-existent semaphore table, until after the updates are run. If you deploy using a version control system, make sure to commit lock.inc to your production codebase. Finally, if you run a bytecode cache such as APC, reset the cache to let it reread the changed files.

Ok, updated to this (quoted verbatim):

Important update notes

Drupal 6.16 unfortunately introduced a change which makes it incompatible with PHP 4 in itself. See #732096: Fatal error: Call to undefined function: array_intersect_key() in url/modules/update/update.compare.inc on line 695 for an upcoming fix to run on PHP 4.

A new includes/lock.inc file is included with this release to support the locking subsystem. This also involved some database changes. To make sure your site continues to function right, running update.php is extremely important. Update.php will display warnings of the non-existent semaphore table, until after the updates are run. If you deploy using a version control system, make sure to commit lock.inc to your production codebase. Finally, if you run a bytecode cache such as APC, reset the cache to let it reread the changed files.

These releases did not change the (default.)settings.php and robots.txt files, so you can keep your existing files intact, if you have modifications in them.

The .htaccess file was changed in Drupal 6.16, adding make files to the list of files not served by Apache. See http://drupal.org/node/638030 for more information.

I'd like to have a patch on the PHP 4 compatibility issue so I can link to a suggested fix for users. I suspect it will be a line or two in changes, which we could tell people to apply manually, and hopefully don't need to rush a 6.17.

What is a definition of a "rushed" 6.17 release?

Today?
Within the next week?
Any time prior to the next future security fix?

Personally, I would sincerely hope there was a 6.17 release inside of a week to resolve this. Users needing to patch Drupal core really shouldn't be an acceptable situation.

And surely the sooner that 6.17 comes out, the less disruption there will be for the people who have yet to start the upgrade?

So far we have received minimal reports from people with PHP 4 that I know of. Putting out a follow up release will give work to the overwhelming majority, who are not affected at all. I'm not happy about this misstep in Drupal 6.16, but pushing out a new release immediately for everybody seems a bit drastic, unless the problem is more widespread.

I've committed a fix to the DRUPAL-6 branch so those running with CVS checkouts can just update to that. For those (expected majority) running on releases, I've put up a one-line change suggestion and updated the front page post:

Drupal 6.16 unfortunately introduced a change which makes it incompatible with PHP 4 in itself. Apply the one-line change explained in http://drupal.org/node/732096#comment-2679226 until a new Drupal release comes out which will include a fix for this issue.

I'll keep monitoring issues people had with Drupal 6.16. There are some people having issues with Drupal 6.16, but in all cases so far, it turned out to be an issue with not following the update process (not setting up maintenance mode, not running update.php, etc). However, if there are actual issues with the code which are not fixed by running the update properly, we should not release 6.17 without fixing them. So we'll need to gather some more experience with results from people's updates. The critical issue queue I'm watching is at http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted...

So all-in-all I think the best we can do is to (a) provide a quick one-line fix for PHP 4 users to minimize their patching needs (b) monitor if there are any critical issues with the codebase that warrant a release. If PHP 4 users don't turn up in masses, then I'd consider the PHP 4 issue not critical enough to warrant a quick follow up release. Same applies to if the other issues all turn out to be process/local configuration problems, as they did so far.

So, should I understand that the 'semaphore' warning is due to an improvement and it's completely harmless?

@b3liev3: yes, it should only appear until you actually run the updates. It will appear on the last update feedback screen, since it displays warnings collected in the update process, but should not display beyond that, because the update actually adds in this table.

Thanks a lot @Gábor Hojtsy.

Afterwards I've done more updates without problems.