If the site is on an insecure version of an old minor and there is a secure version of that old minor available, the update status report should link that release

@xjm asked me to review. I think displaying both versions is fine, it largely depends on the design. The less disruptive update (with same minor) should be displayed with higher prominence, since that is sufficient to resolve the same security issues (IF it is sufficient) and is much lower risk.

We can also display the later minor security update, but that would be in my mind informative if they are working on a site update to that anyway, so they are aware that the bugs are fixed there as well and not just this minor.

The info about the next minor's security fix becomes important when support lengths are taken into account and support is going to be over soon for this minor. That is not in scope here though.

I think between Security Update linking to the latest secure release of the old minor branch and displaying the Latest Version underneath, that covers the important use cases without adding in a third link.

In that case, the simplest solution is to switch the top link to the latest secure release of the old minor branch and leave everything else exactly as it is now.

Here is what the updates page would list now

This a screenshot from the test \Drupal\Tests\update\Functional\UpdateCoreTest::testSecurityUpdateAvailability()
In this case the site is on 8.0.0

It shows both the security release of the sites installed minor and the next minor. But it shows the next minor first. Actually before it shows 8.2.0-rc2 which in the test case is a security release.

So should we reverse the orders of th security releases to start with the current minor and the go up?

Should we make a follow up or new issue to deal with the fact that releases are listed 2x.

I think what happens is the recommended, the latest, and all security releases are listed. And if any of these are the exact same releases there is not check for that.

So you will often get releases that fall into 2 of these categories. Of course if we listed them once we need to have wording to convey that a release is both the recommended and a security release or recommended and latest etc. Or maybe all three in 1 release

At the UX meeting last week, we discussed this issue. We agreed that there is not enough room on the "available updates" report to explain fully the advantages of updating to one version or another. I suggested adding a documentation page with a full discussion and a few short phrases describing the options. Then the "available updates" report can link to that page and use the same short phrases.

I just added a documentation page: https://www.drupal.org/docs/8/update/which-update-should-i-apply. This page is published, and it is part of the "Upgrading Drupal 8" guide, but it has not been added to the menu of that guide.

The "short phrases" I chose are

• least disruptive
• latest and greatest
• bleeding edge

I guess that "latest and greatest" is equivalent to the version labeled "recommended" in the current "available updates" report. I do not like the term "recommended": in some cases, I might recommend the "least disruptive" update.

As the comments above show, we currently list pre-release versions. I added the "bleeding edge" option specifically so that I could say that it is not recommended for a production site.

Here are mockups incorporating the security update. Does everyone feel that we need to show the bleeding edge release here? My impression has been that users who are interested in and able to run the bleeding edge release are not discovering and downloading it through the UI.

Fixing the status

Copying here since Slack history will not last long: the documentation page I added and mentioned in #13 above duplicates content on some other pages. Look at these: most need updating, and we can probably use one of them as a link in the updated "available updates" report:

• https://www.drupal.org/docs/8/understanding-drupal-version-numbers/which...
• https://www.drupal.org/docs/8/understanding-drupal-version-numbers/what-...
• https://www.drupal.org/node/475848
• https://www.drupal.org/core/d8-allowed-changes#alpha

Quoting @xjm on that last one: "which has the actual current definition of what alpha/beta/RCs are, as well as the technical specifics"

I've created the follow up issue for the buttons here: #3000742: Make "Download recommended release" a button rather than a link on update status report

It sounds like we need work on this issue to not repeat releases, so I'm updating the status here.

While we made the Extended Security Support policy change last year, we still haven’t completed this issue, which is critical to to ensure users know about security coverage for their minor and make the right choice in response to security releases. After talking to @xjm, escalating to critical.

This at least seems related to #3100115: The update module should recommend updates based on supported_branches rather than major versions majors. Don't yet fully understand the scope of each issue, but they seem to be talking about very similar things...

Just to say I think the proposed solution here is good - show the latest version in the current branch and also the next branch(es).

Potentially a site could be on 8.8.7, with 8.8.8, 8.9.1 and 9.0.3 all available at the same time.

Like dww, I also think #3100115: The update module should recommend updates based on supported_branches rather than major versions majors is probably a duplicate.

Marked #3100115: The update module should recommend updates based on supported_branches rather than major versions majors as duplicate.

@catch I think we can fold #3100115: The update module should recommend updates based on supported_branches rather than major versions majors into this issue but the current proposed

If the site is on an insecure version of an old minor and there is a secure version of that old minor available, link the latest secure release of the old minor branch on the update status report.

Continue to also provide a link to the latest version.

Only covers insecure installed version and security updates. If we want handle the problem in #3100115 we should always show the latest release for given minor and also the latest release for the major. This would be regardless of whether we were dealing security releases or not.

Also when this issue was created the problem only affected core but since then drupal.org has updated support semantic versioning release for contrib projects. So we would have this same problem in contrib.
So if we want to handle all of the issues in this 1 we will need to have contrib act the same way. Always show the latest release for given minor and also the latest release for the major. This only applies to contrib that have semver releases.

If we want handle the problem in #3100115 we should always show the latest release for given minor and also the latest release for the major.

I think it probably makes sense to show the latest release on the current branch and also the latest releases on any later branches.

This would help people to see exactly how far behind they are on updates, which might give some people a chance to avoid running into #3098475: Add more strict checking of hook_update_last_removed() and better explanation.

FYI: Marked #3127247: Add ability to update to "Also available" module versions related to this since it's asking to change the Update Manager GUI to provide options to update to an 'Also available' releases, not just 'Recommended'. So if we're expanding the choices for also available (based on #26 from @catch), we might want to consider #3127247 in our plans.

As I see this is a security improvement. Why it can't be backported to 9.1.x?

Pretty sure this Automatic Updates because so far we are relying on update_calculate_project_update_status() to determine which module we will update to.

Had a report from @adamps that the 9.2.8 release wasn't marked as insecure when 9.2.9 came out, this is likely because we already have 9.3.0-beta1 etc. and it's hitting this bug.

marked as "closed (won't fix)" without an explanation?

Reverting status, see: #3276540: Block (temporarily?) stephencamilo user for modifying many issues to be "won't fix"

I tried to make some progress here. I tested the patch on 10.0.4 and used those results for the before and after screenshots. It is probably best just to look at those too see the changes.

Fix errors caught by PHPStan

Sigh, and again.

The failure is about themes which I have not worked on yet. This restores drupalci so all tests runs. No interdiff.

This looks like a good change -- list the immediate and simple patch version update first, before the more offputting minor version update.

I notice from the screenshots we've no longer got one of them in bold.

Is there a spec somewhere for what a bold means on the update status report?

A few more fixes:

• The failing test is fixed by finding the element with new label, "Recommended security update".
• I don't know of any spec for the use of bold. It looks like it is simply used to highlight the recommended version.
• This also restore some accidental formatting changes
• Change watchdog_exception to Error::logException(
• New after screenshot

Wondering if this could be answered in the Issue summary

Decide whether to continue linking the latest security release if it is not the latest release overall and the user is on a different minor branch.

If there is a 10.0.9 would that be the recommended security update version?

If there is a 10.0.9 would that be the recommended security update version?

Yes. The screenshot is for a site on Drupal 10.0.4 and there are two security releases after that. It is the latest one that is displayed.

Still to do #56.2. I am setting back to NR because the patch doesn't need work right now. We need to make sure this change fits with the overall plan for what is show on the page.

@quietone who's needed to make that call?

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Convert to MR and hide patches.
And here are some more after images

Same question as before who can make the call. This just sat there before.

Lets see if a submaintainer can chime in.

This screenshot shows that this is still not quite right. For 10.0, the latest security release should be displayed and it is not.

Testing with a Drupal version of 10.1.0 shows the changes made here.

Postponing on #3100110: Convert update_calculate_project_update_status() into a class

This should be done before #2990476: If the site is on an insecure version of an old minor and there is a secure version of that old minor available, the update status report should link that release to avoid making update_calculate_project_update_status() even more complicated

That issue will take much longer to resolve. I think it is more important to fix this Critical bug than wait for an architectural change.

Then can the other issue summary be updated

As usual, this fell off my radar. Tagging to be smashed. I can't do a full subsys maintainer review anytime soon, but trying to remind myself to get back to this ASAP.

@smustgrave (bless his soul!) traded me a review here for his reviews of #2640994: Fix label token replacement for views entity reference arguments (which just landed for 10.3.0 🎉). Finally circling back to uphold my end of the bargain. 😂

In principle, +1 to the general approach of marking the recommended update as "Recommended security update" if it's a security update from the same branch as you're currently running. We want folks to get off known-insecure versions ASAP, and a security release from the same branch is the least disruptive thing to do, so that's what we should "Recommend".

However, I left a detailed review on the MR and opened 9 threads, some of them fairly easy suggestions to review, but a couple of important ones.

I've only looked at the code, haven't tried any manual testing.

One of my key review points is that I don't think the test changes are testing anything about the new functionality, so we need to fix that before we can have confidence from the GitLab pipeline. Probably would be good to do some manual testing, too.

Thanks for keeping this alive and moving forward, and apologies for the long lapses in my availability to review this...
-Derek

p.s. Crediting @smustgrave for all the efforts here, both reviewing and tracking subsystem maintainers, and myself for the detailed review.

So long as the threads are addressed and the tests are actually testing this, I'm happy. So signing off as subsystem maintainer.

@dww and @snustgrave, thanks for working together so this issue got a review!

I have updated the MR and left comments in the MR.

Looks like this needs a reroll

Rerolled and there is a valid test failure. I don't see why yet and debugging these update tests is working as I would like.