#1089320: Update version strings and constants to 8.x tried to convert all version strings in core to D8, but it was clearly a massive grep/replace.

There are just a few instances of 7-x in core/modules/update/tests/fixtures/release-history

The remaining instances are release links that links that have 7-x in the URL when the actual project version is 8-x.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 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. Drupal 8.1.0-rc1 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 Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

Issue summary: View changes

Is this still valid?

quietone’s picture

Didn't finish that comment.

I am not one in the know about update tests but surely a lot has change in the 6 years since this issue was opened and this may be outdated. How to prove that?

dww’s picture

Assigned: Unassigned » dww
Issue tags: +Bug Smash Initiative

I'll look into this in the next few days and assess what, if anything, still needs to happen here.

Thanks for flagging this in #BugSmash -- I had completely forgotten about opening this issue. ;)

Cheers,
-Derek

dww’s picture

Sorry for the delay, this fell off my radar! ;)

Sadly, this isn't outdated. For example:

core/modules/update/tests/fixtures/release-history/bbb_update_test.1_0.xml contains:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns:dc="http://purl.org/dc/elements/1.1/">
<title>BBB Update test</title>
<short_name>bbb_update_test</short_name>
<dc:creator>Drupal</dc:creator>
<supported_branches>8.x-1.</supported_branches>
<project_status>published</project_status>
<link>http://example.com/project/bbb_update_test</link>
  <terms>
   <term><name>Projects</name><value>Modules</value></term>
  </terms>
<releases>
 <release>
  <name>bbb_update_test 8.x-1.0</name>
  <version>8.x-1.0</version>
  <tag>DRUPAL-7--1-0</tag>
  <status>published</status>
  <release_link>http://example.com/bbb_update_test-7-x-1-0-release</release_link>
  <download_link>http://example.com/bbb_update_test-8.x-1.0.tar.gz</download_link>
  <date>1250424521</date>
  <terms>
   <term><name>Release type</name><value>New features</value></term>
   <term><name>Release type</name><value>Bug fixes</value></term>
  </terms>
 </release>
</releases>
</project>

Of particular note:

  <version>8.x-1.0</version>
  <tag>DRUPAL-7--1-0</tag>
  <release_link>http://example.com/bbb_update_test-7-x-1-0-release</release_link>
  <download_link>http://example.com/bbb_update_test-8.x-1.0.tar.gz</download_link>

Part of the trouble would be cleaned up by: #3113798: Remove unused (and generally wrong) <tag> markup from Update module test XML fixtures

That's still lingering in NR, mostly because @tedbow isn't on board, and I haven't convinced him otherwise, nor gotten enough other support for that to do it, anyway. ;)

But some of this is still broken, e.g. <release_link> vs. <download_link> not agreeing.

Not sure if the right solution is to manually/automatically fix things, or remove other attributes from our fixtures that we're clearly not using (or we'd have failing tests).

quietone’s picture

Version: 8.9.x-dev » 9.2.x-dev
Status: Active » Needs review
FileSize
195.63 KB

Based on #12 I made an attempt here. This removes all references to Drupal 7 versions in the fixtures directory. I then went further and modified the release and download links so they were like d.o link.s

quietone’s picture

Did too much in that one. Starting over.

quietone’s picture

@dww, what do you think about expanding the scope to something like 'clean up the fixtures' and include #2995367: Fix update module test fixture names for 8.2.0-rc2 sample data ?

dww’s picture

@quietone: Thanks for continuing to work on this. And for the link to #2995367 - never noticed that one before. ;) Seems tightly scoped already. I basically always defer to release managers for issue scoping decisions, and since xjm opened that one as-is, I think we should just fix that independently.

Thanks again,
-Derek

dww’s picture

p.s. We've already got #3110917: [meta] Fix update XML fixtures bad data as the generic "update the fixtures" meta. Adding that as the parent for this one.

quietone’s picture

@dww. Thanks. Anything else to do here?

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

tedbow’s picture

Title: Update manager tests have a bizarre mix of D7 and D8 versions » Update manager XML test fixtures contain D7 links to D8 releases
Issue summary: View changes
Status: Needs review » Needs work

@quietone and @dww thanks for working on this

I think this 1 is good. Searched under core/modules/update/tests for '7.' and '7-' and only found results in ModuleVersionTest which is intentional.

re

I'm shocked that the Update manager tests are even still passing. ;) That's probably a bug in and of itself...

I checked this out.

We do assert release links in \Drupal\Tests\update\Functional\UpdateTestBase::assertVersionUpdateLinks()

But for the links that are wrong in the XML:

The projects bbb_update_test and ccc_update_test are only used in testUpdateBrokenFetchURL() and testUpdateContribOrder() for these tests we don't need to assert the release link.

For update_test_subtheme and update_test_subtheme we use them \Drupal\Tests\update\Functional\UpdateContribTest::testUpdateBaseThemeSecurityUpdate()

We don't actually assert anything about update_test_subtheme because the test is test whether the base theme update will show.
We currently have

$this->assertRaw(Link::fromTextAndUrl(t('Update test base theme'), Url::fromUri('http://example.com/project/update_test_basetheme'))->toString());

which does assert that there is link to the base theme project page but I think if we changed that to

$this->updateProject = 'update_test_basetheme';
$this->assertVersionUpdateLinks('Security update', '8.x-1.1');

We would assert the release link is correct and would get the added benefit of asserting the actual version number of the security update.

tedbow’s picture

Updated the issue summary to make it easier for committers

quietone’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
807 bytes
4.31 KB

@tedbow, thanks.

#21. Change from assertRaw to assertVersionUpdateLinks.

tedbow’s picture

Status: Needs review » Reviewed & tested by the community

@quietone thanks for the update! Looks good!

  • xjm committed 04e3e8d on 9.3.x
    Issue #1478294 by quietone, dww, tedbow: Update manager XML test...

  • xjm committed f8dc5ae on 9.2.x
    Issue #1478294 by quietone, dww, tedbow: Update manager XML test...
xjm’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 9.3.x and cherry-picked to 9.2.x. Thanks!

xjm’s picture

Version: 9.3.x-dev » 9.2.x-dev

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.