Wrong release date on multi-module projects

Updated patches for D7 and D6. I put a nice long explanation about this problem and the solution in #588308: Always use latest datestamp for project, not just the first one.

Revised patch that won't cause undefined index error if using CVS checkout of Drupal (no datestamp in .info) but not using CVS deploy.

It'd be nice to add a test for this, which will be easy to do once #253501: Tests for update.module lands. Meanwhile, I've reviewed the patch, and tested it, and it's the right fix for an important bug. I solemnly swear I'll add a test for this case once this and #253501 are in, but it's too painful to try to add tests in both issues.

Assuming my latest patch at #253501-21: Tests for update.module is committed, the test for this becomes quite simple:

  /**
   * Ensure proper results where there are date mismatches among modules.
   */
  function testDatestampMismatch() {
    $system_info = array(
      '#all' => array(
        'version' => '7.0-dev',
        'datestamp' => time(),
      ),
      'block' => array(
        'datestamp' => '1000000000',
      ),
    );
    variable_set('update_test_system_info', $system_info);
    $this->refreshUpdateData('dev-snapshot.xml');
    $this->drupalGet('admin/reports/updates');
    $this->assertNoText(t('2001-Sep-'));
  }

and we need to add a 'dev-snapshot.xml' file that looks something like this:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns:dc="http://purl.org/dc/elements/1.1/">
<title>Drupal</title>
<short_name>drupal</short_name>
<dc:creator>Drupal</dc:creator>
<api_version>7.x</api_version>
<recommended_major>7</recommended_major>
<supported_majors>7</supported_majors>
<default_major>7</default_major>
<project_status>published</project_status>
<link>http://example.com/project/drupal</link>
  <terms>
   <term><name>Projects</name><value>Drupal project</value></term>
  </terms>
<releases>
 <release>
  <name>Drupal 7.0</name>
  <version>7.0</version>
  <tag>DRUPAL-7-0</tag>
  <version_major>7</version_major>
  <version_patch>0</version_patch>
  <status>published</status>
  <release_link>http://example.com/drupal-7-0-release</release_link>
  <download_link>http://example.com/drupal-7-0.tar.gz</download_link>
  <date>1250424521</date>
  <mdhash>b966255555d9c9b86d480ca08cfaa98e</mdhash>
  <filesize>1073741824</filesize>
  <terms>
   <term><name>Release type</name><value>New features</value></term>
   <term><name>Release type</name><value>Bug fixes</value></term>
  </terms>
 </release>
 <release>
  <name>Drupal 7.x-dev</name>
  <version>7.x-dev</version>
  <tag>DRUPAL-7</tag>
  <version_major>7</version_major>
  <version_extra>dev</version_extra>
  <status>published</status>
  <release_link>http://example.com/drupal-7-x-dev-release</release_link>
  <download_link>http://example.com/drupal-7.x-dev.tar.gz</download_link>
  <date>1250424581</date>
  <mdhash>b966255555d9c9b86d480ca08cfaa98e</mdhash>
  <filesize>2147483648</filesize>
  <terms>
   <term><name>Release type</name><value>Bug fixes</value></term>
  </terms>
 </release>
</releases>
</project>

I committed #253501: Tests for update.module so maybe we can do a quick re-roll with that test from #7?

Yeah I can roll a quick patch with the test in it.

I made the test a bit more robust (also ensures the report thinks we're up-to-date in this case). Patch now includes it. If you add the test but not the hunk for update.compare.inc, you get test failure. Once you patch update.compare.inc, the tests pass. Yay. Leaving this RTBC, even though it's my own patch...

Committed to CVS HEAD.

Marking as RTBC'd for Drupal 6. Patch in #5.

Committed to Drupal 6 too, thanks.

Sweet, thanks. Just have to backport this to update_status D5 contrib and we're done. Not sure if Dave still wants to do that, so I'll unassign for now. I'll assign to myself if I'm going to start working on it.

Reviewed, tested, and committed #15 to DRUPAL-5--2 of update_status contrib. Thanks, Dave! Moving back to core for posterity...