A pre-release update will be recommended for semantic version updates if the patch number is equal to the patch number from the previous release

Here is a quick patch to demonstrate the fail

1. updates core/modules/update/tests/modules/update_test/drupal.1.1.xml to add 8.2.1-alpha1 release.
   This test should still recommend 8.1.1 because it should not release with "extra" version number unless it comes after 8.2.1. But because 8.1.1 and 8.2.1-alpha1 have the same patch release it will be confused for a "Bugfix" type of release for 8.1.1.

   The test should fail on

   $this->assertVersionUpdateLinks('Recommended version:', $full_version);
   

   on line 128.

the test failure was expected

I think the next step here to turn this into a Merge Request.

Basically all #2 did was add a release to 1 of our test fixtures. This release should not have been recommended and test should still have passed because the site was on a stable non-alpha release the new release added was an alpha.
But test failed which shows the problem.

The tests and the test fixtures have been refactored since this patch was made.

the new test method that this should affect is \Drupal\Tests\update\Functional\UpdateSemverTestBase::testNoUpdatesAvailable().

The new fixture is core/modules/update/tests/fixtures/release-history/drupal.1.1.xml but I think there will be a problem with using this because in the previous patch I was adding a Drupal 8.2.1-alpha1 release which should have been ignored. but now in #3111929: If no recommended update is found, Update Status recommends the latest release, even if it is unsupported we added a Drupal 8.2.0 which is ignored because supported_branches doesn't have 8.2.. So adding Drupal 8.2.1-alpha1 will no longer work to show the bug because it will be ignored because the branch is not supported not because it is an alpha, which is what this issue is trying to prove.

One idea for updating the fixtures:

You can see in the XML fixtures many have <!-- This release is not in a supported branch; therefore it should not be recommended. -->. This is for the 8.2.0 release and 8.2. branch so we can't use that one. We could change all of these fixture to use 8.3.0 release and 8.3. as the unsupported branch.

This would allow use to add a Drupal 8.2.1-alpha1 release and add 8.2. as support branch. In this case Drupal 8.2.1-alpha1 should not be recommended but I think it will because the test is broken.

My advice would be to locally change only 1 fixture currently, for example core/modules/update/tests/fixtures/release-history/drupal.1.1.xml and change the loops in \Drupal\Tests\update\Functional\UpdateSemverTestBase::testNoUpdatesAvailable() to only use this fixture to see if this actually works to prove the bug.

This should be fixed in 9.3.x first

I chatted with @kunal.sachdev and he was going to give it a try when he has time

So I think this bug was actually fixed. If you look that code in the summary

 // 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;
      }
    }

This has been changed a lot. This was fixed in #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates. We use to only care if the patch number had changed so if we had a new version number that had the same major and the same patch then the bug would happen.

Now we have

if ($recommended_version_without_extra !== $release_version_without_extra) {
        $recommended_version_without_extra = $release_version_without_extra;
        $recommended_release = $release_info;
      }

So we are looking at major, minor and patch. So the new will pick up the difference between 8.1.1 and 8.2.1. In the old code, the "2" for the minor would be ignored.

So we could add my suggestion in #14 as a way to prove this is not longer a problem and that the minor version is not ignored. We would also have to update the contrib version of the fixture and update the test to check that 8.2.1-alpha1 is not recommend but it is shown as the "Latest release"

changing this from a "Bug report" to a "Task" as this issue is not about hardening the test coverage not fixing a bug.

Sorry, I work with @kunal.sachdev for the test changes in the branch 3105492-a-pre-release-update but I forgot how complicated it is changing XML files because they are used by multiple tests.

I create a new test only for this specific case. I think the problem is basically a minor, in the test 8.1.0, which does not have any other patch releases, ie 8.1.1 is never released. If this happens and the next minors non-stable release are released, in the test 8.2.0-alpha1 then the only bug would have recommended 8.2.0-alpha1. It should be only listed as "Lasted"

The bug is actually fixed for the reason I explained in #17 but we still need a test to prove it and make sure the bug is not reintroduced.