Drupal issueshttps://lab.civicrm.org/dev/drupal/-/issues2020-10-22T04:39:49Zhttps://lab.civicrm.org/dev/drupal/-/issues/142D8/D9 - Define composer upgrade test protocol2020-10-22T04:39:49ZtottenD8/D9 - Define composer upgrade test protocolWith composer-based distribution, there's an extra dimension/risk that you don't see in D7/WP/BD distribution -- Civi and Drupal build on some of the same packages (eg `symfony/*`), and they pull in various plugins, and the different tem...With composer-based distribution, there's an extra dimension/risk that you don't see in D7/WP/BD distribution -- Civi and Drupal build on some of the same packages (eg `symfony/*`), and they pull in various plugins, and the different templates have different conventions. It is entirely plausible for problems to sneak into the dependency-graph that are then awkward for system-implementers to resolve.
During the test/review/RC processes, we currently run [upgrade tests to check the DB-update procedure](https://github.com/civicrm/civicrm-upgrade-test/) against a range of older DB versions. This would be a sort of parallel for checking the composer-code-update procedure.
Ideally, as part of the release-cycle, one might run an upgrade-matrix. Example:
| Drupal Template | Drupal Version | CiviCRM Old Version | CiviCRM New Version |
| -- | -- | -- | -- |
| `drupal-composer/drupal-project` | `8.7.0` | `5.27.0` | `5.31.0` |
| `drupal/legacy-project` | `8.8.0` | `5.29.0` | `5.31.0` |
| `drupal/recommended-project` | `8.9.0` | `5.28.0` | `5.31.0` |
| `drupal/recommended-project` | `9.0.0` | `5.29.0` | `5.31.0` |
Of course, there are a huge number of permutations, and we're not gonna test all of them, but it would be appropriate to ensure that several distinct (in each column) do get tested.