Problem/Motivation

#3102724: Improve usability of core compatibility ranges on available updates report and other issues there has been confusion about why certain XML features were made they way they were.

We should make it clear.

Proposed resolution

  1. Add comments to each XML fixture in the update module that makes clear why it's data is the way it is
  2. Add comments to test methods to make clear which fixtures they use and why

They might be additions or better ideas for making this clear.

Remaining tasks

All the tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

tedbow created an issue. See original summary.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue summary: View changes
dww’s picture

dww
we/he/they
commented
Related issues: +#3113292: Update module has no tests for changes to status of the installed release (revoked, etc)

Excellent, thanks for opening this! Also came up at #3113292: Update module has no tests for changes to status of the installed release (revoked, etc) so adding that as related.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented

Re

Add comments to test methods to make clear which fixtures they use and why

On thing that confused me when I first started with update tests was 

/**
   * Refreshes the update status based on the desired available update scenario.
   *
   * @param $xml_map
   *   Array that maps project names to availability scenarios to fetch. The key
   *   '#all' is used if a project-specific mapping is not defined.
   * @param $url
   *   (optional) A string containing the URL to fetch update data from.
   *   Defaults to 'update-test'.
   *
   * @see \Drupal\update_test\Controller\UpdateTestController::updateTest()
   */
  protected function refreshUpdateStatus($xml_map, $url = 'update-test') {

This doesn't explicit tell you that values in $xml_map will determine which XML fixtures are used.

At least just updating this @param comment could help make it more clear.

We could even refactor it more to be sometime like

/**
   * Refresh the update status using new update XML fixtures.
   *
   * @param array $project_fixtures
   *   An array of project fixtures where the keys are project names and the
   *   values are the XML fixtures to use.
   * @param string $url
   */
  protected function refreshXMLFixtures(array $project_fixtures);

The $url param is hardly ever used and we could remove it from the new function and make another new function to set it or leave it and make it optional.

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

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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.

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

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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.

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

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Postponed
Related issues: +#3280679: Remove legacy attributes, add supported_branches and consistently name update.module's XML fixtures

AFAICT this is blocked on #3280679: Remove legacy attributes, add supported_branches and consistently name update.module's XML fixtures.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Postponed » Active

#3280679: Remove legacy attributes, add supported_branches and consistently name update.module's XML fixtures is in.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.