[policy, then infra] Bulk update core issues for relevant minor versions

Looking at all the moving around perhaps we should not be attaching issues to real branches at all. Maybe we should be attaching issues to 8-minor and 8-patch that way there'd by way less moving issues about. So for example, if an 8.0.x issue doesn't make it into an 8.0.n patch release it will still be eligible for an 8.1.n patch release because it is attached to 8-patch. And (perhaps more importantly) if an 8.1.x issue doesn't make it into 8.1.0 its next commit chance is 8.2.0 because it is attached to 8-minor.

The thing I like about #2 is that it means all we are thinking about is whether something is patch or major eligible. Once that is decide the issue doesn't need further updates for this. Patch eligible issues have to be tested against the current release branch and the future dev branch. Major eligible only have to be tested against the future dev branch.

One drawback I think would be that the abstract is more difficult for folks to understand than the specific versions (which we've struggled with elsewhere in terms of documenting the release cycle). Another drawback would be that it's not only whether a change is eligible for a patch or minor -- for 1/3 of the time it is also whether the issue is eligible for patch, beta/rc for the upcoming minor, or next development minor.

So I agree with that, but I think we could mitigate it if we also hide the other tags and branches from the version select.

There are about 50 issues filed against 8.x tags at the moment: https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

If we collapse all of that down to 8.x-patch 8.x-minor (+ 7.x, 9.x, 6.x), then there's a 50/50 chance of getting things right if you file an issue against 8.x (but randomly otherwise).

Right now it's reasonable for someone with no prior knowledge to choose any of 8.0.x, 8.1.x or 8.0.1 (or 8.0.0 if they didn't upgrade yet) and as we add more tagged releases and branches the number of choices will go up rather than down.

The period where 8.0.x, 8.1.x and 8.2.x are all open, some commits will happen against all three, some only 8.2.x and 8.1.x, and some only 8.2.x is going to be something everyone has to get used to. I think at that point we're back to things like beta target/rc target since there's a lot more nuance there than semantic versioning provides. The issue there isn't that something cannot go into the upcoming minor version, it's that it won't because we consider that version done except for beta/rc-eligible stuff. Since we're not planning to stop committing issues, then it doesn't affect what people can work on, it just affects what version things will get released in - this is a big difference from beta/rc previously and the version-selector not reflecting actual release version seems an OK trade-off for the simplifications we get otherwise.

Additionally, we could probably integrate the commit notifications on issues with a 'fixed in' version - so something that's fixed in 8.2.x/8.1.x/8.0.x would show as such in the issue metadata when it's actually been committed, if not before.

An alternative approach to requiring bulk updates would be to store in the future some more semantic information: The next patch release (bugs), the next minor release (tasks/features), the next major release (fundamental changes).

There's some discussion about that in #66484: Allow issues to be filed against multiple versions/branches..

Here an untested script for March 2:

// Get core issues with those versions.
$query = new EntityFieldQuery();
$result = $query->entityCondition('bundle', project_issue_issue_node_types())
->fieldCondition('field_project', 'target_id', 3060)
->fieldCondition('field_issue_version', 'value', '8.1.x')
->fieldCondition('field_issue_status', 'value', project_issue_open_states())
->fieldCondition('field_issue_status', 'value', 2, '!=')
->execute();
// Load in batches of 50 and update.
$followup_account = user_load(variable_get('project_issue_followup_user', 0));
foreach (array_chunk(array_keys($result['node']), 50) as $nids) {
  foreach (node_load_multiple($nids) as $node) {
    print 'Updating ' . $node->nid . ' ' . $node->title . "\n";
    $node->field_issue_version[LANGUAGE_NONE][0]['value'] = '8.2.x';
    $node->nodechanges_uid = $followup_account->uid;
    $node->nodechanges_comment['comment_body'][LANGUAGE_NONE][0] = array(
      'value' => '<a href="/drupal-8.1.0-beta1">Drupal 8.1.0-beta1</a> has been released, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the <a href="/core/release-cycle-overview#minor">Drupal 8 minor version schedule</a> and the <a href="/core/d8-allowed-changes">Allowed changes during the Drupal 8 release cycle</a>.',
      'format' => filter_default_format($followup_account),
    );
    // Do not send mail notifications.
    $node->nodechanges_comment_attributes = array(
      'project_issue_no_email' => TRUE,
    );
    node_save($node);
  }
}

This looks for "8.1.x" issues, which are open, and not Fixed. And updates the version to 8.2.x.

Note to self: I forgot to hack around not updating the updated date.

Good news: we apparently planned ahead for that sort of hack:

function project_issue_node_presave($node) {
  if (isset($node->_project_issue_changed_timestamp)) {
    $node->changed = $node->_project_issue_changed_timestamp;

This looks like it will work well for the 8.1.x to 8.2.x move:

$query = new EntityFieldQuery();
$result = $query->entityCondition('bundle', project_issue_issue_node_types())
->fieldCondition('field_project', 'target_id', 3060)
->fieldCondition('field_issue_version', 'value', '8.1.x-dev')
->fieldCondition('field_issue_status', 'value', project_issue_open_states())
->fieldCondition('field_issue_status', 'value', 2, '!=')
->range(0,1) //testing
->execute();
print count($result['node']) . " issues\n";
// Load in batches of 50 and update.
$followup_account = user_load(variable_get('project_issue_followup_user', 0));
foreach (array_chunk(array_keys($result['node']), 50) as $nids) {
  foreach (node_load_multiple($nids) as $node) {
    print 'Updating ' . $node->nid . ' ' . $node->title . "\n";
    $node->field_issue_version[LANGUAGE_NONE][0]['value'] = '8.2.x-dev';
    $node->nodechanges_uid = $followup_account->uid;
    $node->nodechanges_comment['comment_body'][LANGUAGE_NONE][0] = array(
      'value' => '<a href="/drupal-8.1.0-beta1">Drupal 8.1.0-beta1</a> has been released, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the <a href="/core/release-cycle-overview#minor">Drupal 8 minor version schedule</a> and the <a href="/core/d8-allowed-changes">Allowed changes during the Drupal 8 release cycle</a>.',
      'format' => filter_default_format($followup_account),
    );
    // Do not send mail notifications.
    $node->nodechanges_comment_attributes = array(
      'project_issue_no_email' => TRUE,
    );
    $node->_project_issue_changed_timestamp = $node->changed;
    node_save($node);
  }
}

Just a note I'm going to try to get the beta out and branch 8.2.x in the next 2-3 hours. For me this bit could happen any time before the end of the week - so fine if it's just after but don't wait up for me. A bit timezone/baby constrained today.

8.2.x is branched and the release node posted - although still packaging so not in the version selector yet.

No major hurry here, but hopefully things are now ready to go from the core side of things.

This will update 1,735 issues. That looks like it matches https://www.drupal.org/project/issues/drupal?text=&status=Open&prioritie...

I ran it on a sample issue: #2004: Finer-grained book controls

I'm guessing the odd date was a spam comment that was deleted.

I see now the issue queue uses the last comment timestamp. We could back-date the comments, it looks technically possivble. That will look quite weird if anyone pays attention to the comment time in the individual issue pages. That only shows on hover for comment, so maybe that is acceptable?

I belive that worked, #2780: How About a Book Javascript TOC Tree.

Here's the new script:

$query = new EntityFieldQuery();
$result = $query->entityCondition('bundle', project_issue_issue_node_types())
->fieldCondition('field_project', 'target_id', 3060)
->fieldCondition('field_issue_version', 'value', '8.1.x-dev')
->fieldCondition('field_issue_status', 'value', project_issue_open_states())
->fieldCondition('field_issue_status', 'value', 2, '!=')
->range(0,1) //testing
->execute();
print count($result['node']) . " issues\n";
// Load in batches of 50 and update.
$followup_account = user_load(variable_get('project_issue_followup_user', 0));
foreach (array_chunk(array_keys($result['node']), 50) as $nids) {
  foreach (node_load_multiple($nids) as $node) {
    print 'Updating ' . $node->nid . ' ' . $node->title . "\n";
    $node->field_issue_version[LANGUAGE_NONE][0]['value'] = '8.2.x-dev';
    $node->nodechanges_uid = $followup_account->uid;
    $node->nodechanges_comment['comment_body'][LANGUAGE_NONE][0] = array(                                                                                                                  'value' => '<a href="/drupal-8.1.0-beta1">Drupal 8.1.0-beta1</a> was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the <a href="/core/release-cycle-overview#minor">Drupal 8 minor version schedule</a> and the <a href="/core/d8-allowed-changes">Allowed changes during the Drupal 8 release cycle</a>',
      'format' => filter_default_format($followup_account),
    );
    // Do not send mail notifications.
    $node->nodechanges_comment_attributes = array(
      'created' => $node->last_comment_timestamp,
      'project_issue_no_email' => TRUE,
    );
    $node->_project_issue_changed_timestamp = $node->changed;
    node_save($node);
  }
}

Does this look okay to run on the rest?

Hacking last comment date seems fine to me - it's last commented or updated anyway.

These are bulk updating now. Setting back to active for the April 6 update.

I think comment #6 has the best version of that message so far. It should also mention the date in the text, and be rolled into a version of the script in #25 with other values changed appropriately.

Perhaps exclude experimental modules next time? BigPipe & Migrate issues should continue to be against 8.1.x-dev AFAIK.

this is really great.

and cause it links to the allowed changes doc
it relates to #2572061: Add a dismissable notification when somebody goes to a core issue while in RC

There will also be issues moved back to 8.0.x after commit to 8.1.x or 8.2.x not at that status - i.e. if a patch was posted but needs work, or if there was already a patch in the issue, or if the 8.1.x/8.2.x patch cherry picks but there's discussion whether it's a good idea or not.

#10566: Forum can not appear in multiple containers is the test issue this time.

This will update 7,157 more issues, which matches https://www.drupal.org/project/issues/drupal?text=&status=Open&prioritie....

Looks good other than: instead of "upgrade to 8.1.0.", it should say "update to 8.1.0." it is not an upgrade.

I'll be starting the bulk update shortly.

This has run. For posterity, the script was

$query = new EntityFieldQuery();
$result = $query->entityCondition('bundle', project_issue_issue_node_types())
->fieldCondition('field_project', 'target_id', 3060)
->fieldCondition('field_issue_version', 'value', '8.0.x-dev')
->fieldCondition('field_issue_status', 'value', project_issue_open_states())
->fieldCondition('field_issue_status', 'value', 2, '!=')
->range(1,100)
->execute();
print count($result['node']) . " issues\n";
// Load in batches of 50 and update.
$followup_account = user_load(variable_get('project_issue_followup_user', 0));
foreach (array_chunk(array_keys($result['node']), 50) as $nids) {
  foreach (node_load_multiple($nids) as $node) {
    print 'Updating ' . $node->nid . ' ' . $node->title . "\n";
    $node->field_issue_version[LANGUAGE_NONE][0]['value'] = '8.1.x-dev';
    $node->nodechanges_uid = $followup_account->uid;
    $node->nodechanges_comment['comment_body'][LANGUAGE_NONE][0] = array(
      'value' => '<a href="/drupal-8.0.6-release-notes">Drupal 8.0.6</a> was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. <a href="/drupal-8.1.0-rc1">Drupal 8.1.0-rc1</a> is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the <a href="/core/release-cycle-overview#minor">Drupal 8 minor version schedule</a> and the <a href="/core/d8-allowed-changes">Allowed changes during the Drupal 8 release cycle</a>.',
      'format' => filter_default_format($followup_account),
    );
    // Do not send mail notifications.
    $node->nodechanges_comment_attributes = array(
      'created' => $node->last_comment_timestamp,
      'project_issue_no_email' => TRUE,
    );
    $node->_project_issue_changed_timestamp = $node->changed;
    node_save($node);
  }
}

In addition to the usual changes, I lowered the batch size down to 100 and called the script a bunch of times while sleeping in between.

Setting back to active in case there are future similar requests.

@drumm: now that https://groups.drupal.org/node/512705 is near, next week will be the time to do another bulk update due to the 8.2.0 beta. Do you prefer to keep using this issue or open yet another one instead?

Either works for me. I slightly lean toward a fresh one, 45 comments in an issue is plenty. Can be opened in the infra or drupalorg project, unless visibility in the core issue queue is needed.

@drumm: All right, agreed opened #2772437: Bulk update 8.2.x Drupal core issues to 8.3.x.

Is this issue fixed, or does it stay open until there's less-bespoke automation?

@drumm: I think its better to not mark fixed since we only have the bespoke solution, even if it only needs to run four times a year (twice for betas, twice for EOL of a branch).

Next up is #2790511: Bulk update 8.1.x Drupal core issues to 8.2.x once 8.2 RC is out opened that.

Updating the IS as a result of discussing talking to xjm.

What should be the last bulk update was completed in #3414011: Bulk update for remaining issues to 11.x (main). I think this can be closed now.

The IS was updated in #60.

Yes let's close this out.

We'll need one last bulk update for 11.x -> main but that'll be its own entirely separate process.