Talking as project administrator on drupal.org, as far as I recall, you cannot create the same release twice; you need to create another release. You could delete the last release and recreate it, but I am not sure the Update manager module would notify users of a new release; if it did, I guess users would be confused about being notified of a new version that is the same they have.
If I understand correctly, the issue is that your update hook contained the following code.
$rows_updated = db_update('role_permission')
->fields(array('permission' => 'schedule publishing of nodes'))
->condition('permission', 'schedule (un)publishing of nodes', '=') ->execute();
return format_plural($rows_updated, '1 row updated in role_permission table.', '@count rows updated in role_permission table.');
Then, you changed it to the following one.
// Updates done in two stages to avoid integrity constraint violation.
// @see http://www.drupal.org/node/2706119
// Select all role ids which already have the new permission value.
$query = db_select('role_permission', 'rp')
->fields('rp', array('rid', 'permission'))
->condition('permission', 'schedule publishing of nodes');
// Delete the rows for these roles which also have the old permission value,
// as these are no longer needed and should not be updated to the new value.
$rows_deleted = 0;
if ($rows_to_delete = $query->execute()->fetchCol()) {
$rows_deleted = db_delete('role_permission')
->condition('rid', $rows_to_delete, 'IN')
->condition('permission', 'schedule (un)publishing of nodes', '=')
->execute();
}
// Now update any other rows which still have the old permission value.
$rows_updated = db_update('role_permission')
->fields(array('permission' => 'schedule publishing of nodes'))
->condition('permission', 'schedule (un)publishing of nodes', '=')
->execute();
return format_plural($rows_deleted, '1 row deleted', '@count rows deleted')
. ', ' . format_plural($rows_updated, '1 row updated', '@count rows updated')
. ' ' . t('in role_permission table');
As I understand it, the new code is supposed to replace the old code, and your problem is that there are users who already run the update the update #7102. If that is the case, then I would rename scheduler_update_7102() (with the new code) scheduler_update_7103(). In this way:
- The users who didn't do the update will not run the old
scheduler_update_7102() and they will not get the error
- The users who already ran
scheduler_update_7102() will find scheduler_update_7103() which completes the update for them.
