Whilst reviewing #2677532: Move drupal_check_incompatibility() functionality to a new Dependency class and Version component → I've discovered a significant bug in the current code both HEAD and with the patch. It's caused by how we prepare the version string for checking compatibility against it.
The suspect code is:
$version = str_replace(\Drupal::CORE_COMPATIBILITY . '-', '', $required_file->info['version']);
If $required_file->info['version']) is 8.x-8.x-beta1 this would mean that we'd check the version using the string beta1 where the intention is to pass 8.x-beta1. A version string of 8.x-8.x-beta1 might feel unlikely but it is very possible. Panels is on 8.x-4.x for example.
Once
#2677532: Move drupal_check_incompatibility() functionality to a new Dependency class and Version component →
lands, I think we should move the $version = str_replace(\Drupal::CORE_COMPATIBILITY . '-', '', $required_file->info['version']); functionality into \Drupal\Component\Extension\DrupalVersionRequirement::isCompatible() so callers don't have to think about this at all. So it supports both '8.x-3.0-beta1' and '3.0-rc1' for example.
None
None - the suggestion solution widens the strings that \Drupal\Component\Extension\DrupalVersionRequirement::isCompatible() accepts.
None
Active
11.0 🔥
Last updated
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This came up as a BugSmash triage target. It sounded so familiar when I saw the summary in Slack that I thought I had opened this bug report. 😅 nope, I was thinking of #3093789: system_requirements() strips core compatibility in really fragile and dangerous way when comparing versions → and friends. 😂