After updating to 11.3.10, available updates page shows 11.3.9 as a newer version

Everything could be strange until packaging is done and update status data is refreshed. This probably solves itself :-)

Feel free to re-open if it doesn't.

See it too.

I'm not sure there's much update.module can do about this. This is because folks (rightly) upgraded as soon as composer saw the new releases. But since the d.o packaging stuff is still running, the latest aren't yet visible in the release history feeds at updates.drupal.org.

It's a little weird to add code to update.module to handle this, but certainly lots of folks were confused in Slack about it. So maybe it's worth a special case for "looks like you're running something bleeding edge, before the release history knows about it... here's a biscuit." more or less. 😂

Looks fine now for me.

Packaging for these releases is not complete. Please check back tomorrow, refresh your site's update data, and see if this problem still occurs then. Thanks!

There's no more info needed. We all understand 100% what's happening here. People upgraded before the releases landed in the release history feeds.

I'm open to the (small) possibility it's worth adding a special case in update.module to report something else than what the IS/screenshot shows during these short (but highly stressful) windows when "everyone" is freaking out. 😅 That's the only question we still need to assess and resolve.

Related possible discussions:

Consider not pushing to Packagist until the D.O. side is ready.

Investigate solving the reported issue that releases currently have to be built serially (which appears to be an underlying trigger for this)

Note: this issue was raised last month on Slack with the security team.

Would this (or something similar) be an improvement? It's a 6 line diff if we want this. We'd need to add tests for it, which would make it more than 6 lines. 😅 Wanted feedback on if this is worth pursuing. Not worth an MR and spending CI cycles on this until we're a little closer to agreement on if/what we should do in this situation.

Consider not pushing to Packagist until the D.O. side is ready.

This is a chicken-and-egg problem because what the "d.o side" is blocked on for a lot of the time between push and "release node published" is... subtree splits and preparing the packages for Packagist. The tags need to exist in a public repo for Packagist to make anything out of them.

Also, as a reminder, the Security Team has no control over either core or d.o infrastructure.

@dww, switching to RM hat, I honestly have no idea what that change set is doing without test coverage. :D Manual testing would also help but that is always a huge fuss if we have to fake update data also.

Honestly, I don't think this is that big of an issue. Caches gonna cache. The only reason that this is even noticeable is that (a) we are supporting 2x as many branches as we ever did before (or even more than that for today's release) and (b) packaging times were upgraded for the new d.o, but as a side effect they are now taking close to 30 mins per core release instead of 11-12.

Hopefully, future optimizations will reduce packaging times again so that people don't get so antsy about it during the window.

Because I refuse to use LLMs to generate slop, and I didn’t want to bother updating test coverage if it’s gonna be shot down. 😅 I didn’t seriously think anyone was going to commit this patch directly. It’s a PoC. If this issue is “works as designed”, so be it. I’m only trying to show it’s not that hard to improve this situation if we wanted to.

Usability review

We discussed this issue briefly at #3590325: Drupal Usability Meeting 2026-05-22. That issue will have a link to a recording of the meeting. The attendees at the usability meeting were benjifisher, rkoller, and simohell. I am giving them credit on this issue.

Besides the comments on Slack around this week's security release, one of us has run into this problem with client sites during previous updates. Perhaps it comes up more frequently than we have been assuming. When it does come up when installing a security release, it is a stressful time, so anything we can do to make it easier is a good idea.

We feel that the proposed change is a useful improvement to the report page. I am adding the Usability tag. Of course, that usability opinion has to be balanced against the reservations from the release manager in earlier comments.

Looking at the mockup (Comment #11), the text meets the standard requirements for a status message: it says what the current state is and it recommends what to do about it. But there is room for improvement:

1. Move the warning message outside the table, perhaps to the messages area. (Warning does seem to be the right message level.)
2. Use full sentences, and start a new sentence instead of using a "comma splice".
3. Do not use the phrase "Current release". Be explicit about the version you mean.

We did not have time at the meeting to come up with a firm suggestion, but you can use this as a starting point for the message text:

The installed release (10.6.9) is not in the feed of available releases. Try again later, or check manually.

(There is a link to "Check manually" on the same page, so I think the last recommendation is actionable. I think I saw a comment on Slack from dww that it is a useful thing to try. It might even be worth repeating the link next to the "Last checked" timestamp.)

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Back to NW to consider the recommendations in Comment #15.