Rename the modules

I would rather use what Dave suggested.
You keep to say sitemap report, but it's not clear to me what that would mean.

XML sitemap is better; I also agree to leave XML sitemap to mean the module, and not drop it in favor of sitemap.

Would not we add specific code, if we are going to rename XML Sitemap: Term? I mean an update function of XML Sitemap that would verify if xmlsitemap_term.module was enabled, and enable xmlsitemap_term.module (or something like that).

In alternative, we don't add any code like that, and the user simply delete the old files, and copy the new ones.

I would wait a little to change the name of the xmlsitemap_term module, but I would do it in the 6.x-1 branch too.

It should be better if we change the name for xmlsitemap_term also; this would simplify the documentation, which would make reference to only one module, and would avoid problems with the users, who could find themself with xmlsitemap_term, and xmlsitemap_taxonomy when they update to 2.x.

Before to release a release candidate, I would release a beta release, at least; even if the quality of the code could make the release a release candidate, I would rather release it as beta.

To rename xmlsitemap_term should not be too hard, especially if it is done in steps, and trough different pre-releases that the user should pass through.

• The code is passed to the new files. The old files will still be present, but they will not contain code; The description for the module advices that the module is replaced by xmlsitemap_taxonomy.
• The new module rename the database table it uses (optional).
• The old files are completely removed.

I would leave out the French translation; for what I can see, the file is wrong because it declares to take the strings from all the modules.

Is xmlsitemap_taxonomy_update_6113() needed?

Yes, it is.
I was thinking it could be implemented differently, but effectively you chose the right way. The number of variables used by the module increases with the number of vocabularies used; therefore, the way you implemented it is the only possible.

I will take care of this, if it's fine with the others.

I should have done it correctly. I keep the report open for review.

The code needs to be changed from

function xmlsitemap_taxonomy_update_6113() {
  $result = db_query("SELECT name FROM {variable} WHERE name LIKE 'xmlsitemap\_term\_%'");
  while ($row = db_fetch_object($result)) {
    $new_name = preg_replace('/_term_/', '_taxonomy_', $row->name);
    $ret[] = update_sql("UPDATE {variable} set name = '$new_name' WHERE name LIKE 'xmlsitemap\_term\_%'");
  }
  $ret[] = update_sql("UPDATE {xmlsitemap} set module = 'xmlsitemap_taxonomy' WHERE module = 'xmlsitemap_term'");
  return $ret;
}

to

function xmlsitemap_taxonomy_update_6113() {
  $ret[] = update_sql("UPDATE {xmlsitemap} set module = 'xmlsitemap_taxonomy' WHERE module = 'xmlsitemap_term'");
  return $ret;
}

function xmlsitemap_taxonomy_update_6114() {
  $ret = array();
  $result = db_query("SELECT name FROM {variable} WHERE name LIKE 'xmlsitemap\_term\_%'");
  while ($row = db_fetch_object($result)) {
    $new_name = preg_replace('/_term_/', '_taxonomy_', $row->name);
    $ret[] = update_sql("UPDATE {variable} set name = '$new_name' WHERE name = '". $row->name ."'");
  }
  return $ret;
}

This is because the update_sql("UPDATE {variable} set name = '$new_name' WHERE name LIKE 'xmlsitemap\_term\_%'") line would change the name of the Drupal variables that are like xmlsitemap\_term\_% to $new_name.

I will take care of it, when we agree on that.

The point is that the update query is wrong; it selects all the Drupal variables that have a name starting with xmlsitemap_term_, and change the name to the content of a variable. This means that the first time the query is executed, it would change all the variables it finds, and the further queries will not change anything.

It's not a matter of inter-dev versions, but to fix an error present in the code.

EDIT: sometimes my English is not so English.

I changed the code; the call to preg_replace() has been replaced with a call to str_replace(), and the call to db_fetch_object() has been replaced with a call to db_result() (db_fetch_object() is not required when the query returns the value of a single field, as stated in the documentation for db_result()).

Uhmmm... db_result() returns the field as scalar value; therefore, there is no need to write $row->name, but $name.

preg_replace() should not be called if the search string doesn't contain any special characters. If the search engine would be /xmlsitemap_.*_cron_list/i, then I would use preg_replace(); in the specific case, there is no need to do such thing.
The PHP documentation for str_replace also reports that if you don't need fancy replacing rules (like regular expressions), you should always use this function instead of ereg_replace() or preg_replace().

I checked if db_result() could be able to return all the field values contained in the database table, in the case the condition would be matched by more rows; after I verified that the function is able to return all the field values matching the condition (one by one), I changed the code.