discovered in #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates →
In above issue #3105463: Create tests for recommended bugfix releases → was split out to create missing test coverage. Test coverage was added for contrib but for core there is bug that could happen in a very special case. This likely to never happen in core releases but that same problem could happen contrib during #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time →
In update_calculate_project_update_status() docblock there is explanation of how recommended releases are determined.
*
* - 1.6-bugfix <-- recommended version because 1.6 already exists.
* - 1.6
*
* or
*
* - 1.6-beta
* - 1.5 <-- recommended version because no 1.6 exists.
* - 1.4
*
In the example there is not special logic around the "bugfix" string just the extra string and whether the regular version comes before or after the version without the extra string at the end.
The code related to this works for 8.x-1.0 style projects
// Look for the 'recommended' version if we haven't found it yet (see
// phpdoc at the top of this function for the definition).
if (!isset($project_data['recommended'])
&& $release['version_major'] == $target_major
&& isset($release['version_patch'])) {
if ($patch != $release['version_patch']) {
$patch = $release['version_patch'];
$release_patch_changed = $release;
}
if (empty($release['version_extra']) && $patch == $release['version_patch']) {
$project_data['recommended'] = $release_patch_changed['version'];
$project_data['releases'][$release_patch_changed['version']] = $release_patch_changed;
}
}
But in the case where project with semantic version releases like so:
1.2.0-alpha
1.1.0
1.0.0
1.0.0-alpha
If the site is currently on 1.0.0 the recommended release should be 1.1.0. But actually 1.2.0-alpha will be recommended.
This because the code above assumes there will be no minor releases and that there won't be 2 releases with the same minor.
The reason we don't see this problem currently in core is that the above release would not happen. If the releases were instead
1.2.0-alpha
1.1.1 // New release no in example above
1.1.0
1.0.0
1.0.0-alpha
Then 1.1.1 would be recommended which is correct.
The bug only happens when you release in order where the first is pre-release and the next is stable release for the previous minor with the same patch number.. Because this situation doesn't happen in core we don't see the problem.
This could happen in contrib after #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time → .
The current patch in #3074993-82: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates → has a fix for this problem because it takes into account the whole version number extra the "extra" part.
We should confirm it is fixed and add tests in #3100386: Create contrib update module test cases that use semantic versioning →
If it is fixed we can just close this issue.
Needs work
10.1 ✨
Used to track the progress of issues reviewed by the Drupal Needs Review Queue Initiative.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.
Removing the tests tag as I see them in MR1463
Can the MR be updated for 10.1 please.
The open threads were those just comments you had or changes that are needed?