xmlsitemap-6.x-1.0-rc1 Ready, Set, Go

I will gladly test once the RC1 is there.

subscribe

subscribe

Major next beta blocker: #458546: Cache files are not created.

RC should be string freezed if possible. See

#470792: Translatable strings review
#470778: Constant floating numbers shown in the user interface must be translatable

Oh my goodness... this beta6 release is a burden on the xmlsitemap users!

1. Nobody need to disable any module.
2. Enable maintenance mode
3. Users need to delete the module folder
4. Than unpack the new version
5. Run update.php (also clears all caches automatically and need to run after EVERY update - we all know this!)
6. Ready

If this is new for someone, read d.o standard update rules for Drupal.

Telling a user to make sure all tables are deleted is more than strange. You can do this with an update hook. This is why we have an update system... "(Make sure you set the cron limit first.)" is why get_variables have a default value... nothing a user need to do, too - or an update hook need to care about!

@hass: You'd be suprised at the number of users that don't realize they need to run update.php after uploading new versions of modules.

@Dave: I'm aware about this, but core complains if you access "admin"... and point you to the status page and so on. If people cannot read we cannot help them :-). Nevertheless - this is the way how we update modules for ages in Drupal and how it's documented! All guys who knows how to update in the Drupal way would struggle if this manual update path is required.

@earnie: If it works via update.php, ok - but if not - clearly spoken (sorry) - it's unprofessional not to implement the appropriate update hooks for a clean update. The maintainers need to know very very best what need to be rolled back or forth from beta5 to beta6. I will never uninstall my modules and remove tables manually (very unprofessional)!??? Only because of this release notes to-do list I would delay an update or stay where I am for a long time. The reason is simple - the code need to be soooo buggy that I may risk my site. I have no idea what you mean with comfort level isn't good for me, but in such a case it would be better to write a few lines with an update hook to make it better.

Drupal core also allows a seamless upgrade from beta version to beta version, to RC and final. You are completely right if you say you do not need to support inter DEV updates (nevertheless it's better to have them), but between "official releases" (you made the beta official!) an upgrade should work well. I think the main issue that hurts here is that users are made to use the betas because we are all hot for an final D6 release for 1.5 years. Therefore you should better care about the beta upgrade path via update hooks. Be user friendly / admin friendly...

@hass: We are trying to do that. The unfortunate reality is that the beta4/beta5 releases (that were not coded by myself or Earnie) didn't have clean upgrade either in addition to changing the fundamental and expected way the module worked. If you have been at all following what's been happening, you would know that we had to reset the code, and trying to code the upgrade paths would be a huge, buggy task.

Let's even look at the last update function in xmlsitemap.install from beta5:

function xmlsitemap_update_6000() {
  $ret = array();
  if ($GLOBALS['db_type'] == 'pgsql') {
    $result = @update_sql("DROP AGGREGATE first(anyelement)");
    if ($result['success']) {
      $ret[] = $result;
    }
    $result = @update_sql('DROP FUNCTION IF EXISTS first(anyelement, anyelement);');
    if ($result['success']) {
      $ret[] = $result;
    }
  }
  if (db_table_exists('xmlsitemap_additional')) {
    db_drop_table($ret, 'xmlsitemap_additional');
  }
  if (db_table_exists('xmlsitemap')) {
    db_drop_table($ret, 'xmlsitemap');
  }
  foreach(xmlsitemap_schema() as $table => $definition) {
    db_create_table($ret, $table, $definition);
  }
  $modules = array(
    'xmlsitemap_file',
    'xmlsitemap_helper',
    'xmlsitemap_menu',
    'xmlsitemap_term',
  );
  module_disable($modules);
  $ret[] = update_sql("DELETE FROM {system} WHERE name IN ('xmlsitemap_file', 'xmlsitemap_helper', 'xmlsitemap_menu', 'xmlsitemap_term') AND type = 'module'");
  if (db_table_exists('xmlsitemap_file')) {
    db_drop_table($ret, 'xmlsitemap_file');
  }
  $ret[] = update_sql("DELETE FROM {menu_links} WHERE menu_name = 'menu-xmlsitemap'");
  $ret[] = update_sql("DELETE FROM {menu_custom} WHERE menu_name = 'menu-xmlsitemap'");
  $ret[] = update_sql("DELETE FROM {variable} WHERE name LIKE 'xmlsitemap\_menu\_%'");
  if (!variable_get('menu_rebuild_needed', FALSE)) {
    variable_set('menu_rebuild_needed', TRUE);
    $ret[] = array(
      'success' => TRUE,
      'query' => 'UPDATE MENU CALLBACKS',
    );
  }
  return $ret;
}

function xmlsitemap_update_6147() {
  return xmlsitemap_update_6000();
}

According to this, your tables were dropped, data lost, and the tables recreated. This is not an upgrade path and not how the module should have worked. We are addressing this situation now with the utmost seriousness. From here on past beta6 we will not be making major changes to the data architecture, and we will have upgrade paths in place.

This module is not Drupal core. We don't have the hundreds of thousands of developers submitting patches and a testbot testing all those patches for breakage. We have only two active maintainers and we're doing our best to rectify the situation and ensure that this kind of slip-up does not happen again in the future.

According to this, your tables were dropped, data lost, and the tables recreated.

That is partially true (tables of not anymore used modules were not created). What should be said is that the majority of the dropped tables were used from modules that have been removed. The xmlsitemap_additional table is dropped, but that is done because it had a different structure in the 6.x-0, and 5.x-2 branches.

I'm going from 6.x-1.x-beta05 to 6.x-1.0-rc1, but would like some help with this section in the INSTALL.txt if someone can lend a hand:

5) Make sure there are no variables left in the variable table WHERE name LIKE
'xmlsitemap%'.

6) Make sure there are no rows left in the system table WHERE name LIKE
'xmlsitemap%'.

Step 4 was "Make sure the xmlsitemap tables are no longer available in the database." and I did that one just fine.

But I'm not sure where to go in phpMyAdmin to make sure steps 5 and 6 are carried out so there are no instances of 'xmlsitemap' elsewhere.

Great module and thanks in advance for any help.

Replace "variable" with the effective name of the database table; if your Drupal installation is set to use table prefixes, the name of the table will be different. The same is true for "system".