Running Update on latest dev - get An error occurred. http://hoslotracer.com/update.php?id=255&op=do
Fatal error: Call to undefined function xmlsitemap_term_update_6000() in /usr/home/hoslo/public_html/sites/all/modules/xmlsitemap/xmlsitemap_taxonomy/xmlsitemap_taxonomy.install on line 311

Comments

Starminder’s picture

Starminder commented

Also:

* warning: array_merge() [function.array-merge]: Argument #2 is not an array in /usr/home/hoslo/public_html/update.php on line 174.
* user warning: Multiple primary key defined query: ALTER TABLE xmlsitemap_node ADD `nid` INT unsigned NOT NULL DEFAULT 0, ADD PRIMARY KEY (nid) in /usr/home/hoslo/public_html/includes/database.mysql-common.inc on line 298.
* user warning: Multiple primary key defined query: ALTER TABLE xmlsitemap_node ADD `nid` INT unsigned NOT NULL DEFAULT 0, ADD PRIMARY KEY (nid) in /usr/home/hoslo/public_html/includes/database.mysql-common.inc on line 298.
* warning: Invalid argument supplied for foreach() in /usr/home/hoslo/public_html/update.php on line 338.

The update process was aborted prematurely while running update #6107 in xmlsitemap_taxonomy.module. All errors have been logged. You may need to check the watchdog database table manually.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (won't fix)

Intra development updates are not supported. You must uninstall the module using the Uninstall tab of admin/build/modules, remove the modules/xmlsitemap directory, and then install the new -dev version.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Title: Fatal Error Database Update » Fatal database update error

This means that who passes from an old version 6.x-1.x-dev to a newer version of 6.x-1.x-dev must uninstall the module all times, with the consequence that the sitemap is reset all times a new version of the same development snapshot is copied.
I am not sure people will happily use the newest development snapshot, if they are said to uninstall the module all times.

Starminder’s picture

Starminder commented

Ridiculous

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Starminder, I'm sorry this version has been very troublesome lately. Things probably wouldn't have gotten this bad, but we had a maintainer who made significant and unapproved changes to the module that severely diverted its development from the intended focus. We are now having to work hard to reverse the damage done (since there were two releases created with the changed code). If you are using a -dev build doesn't mean that upgrading between -dev versions isn't supported. They are just not written yet. Using -dev builds on a production site is not recommended. Consider this scenario:

11:45 PM GMT: I add or remove a feature from XML sitemap
12:00 PM GMT: The drupal.org packaging script runs, creating a new -dev build
12:05 PM GMT: I finish coding an upgrade path for the new feature.

When you use a -dev build, you are assuming a certain amount of risk. This applies for all modules, not just XML sitmeap. We do not have control over stopping the development build from running to avoid people using a build without an upgrade path. Again, we are trying to do the best to undo the damage done to the module's development. Earnie and I are working the best we can with the free time that we can allot to this module to get this accomplished. We know everyone is frustrated. I understand that completely. Please give us some time and patience and we can deliver.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

A code roll-back should not remove features, or tasks that have been implemented because of an agreement with two maintainers about one month ago.
What a previous maintainer did is not an excuse to not correctly apply a code roll-back, which should not re-introduce bugs the previous committed code resolved.

I find difficult to explain to XML sitemap users that a bug introduced by a recent commit will not be fixed because intra-development updates are not supported (I would like to know which project maintainer currently support such way of proceed), and I find also difficult to make a user understand why a bug has been reintroduced by last commit, when the bug was resolved before.
The excuse of not being responsible for what done from a previous maintainer doesn't work; in that case, the only responsible for the bugs still present in the code would be solely the maintainer who created the project, and who created the first version of the module(s).