It might be safer to do:

The reason being that it's possible for plugin versions to have -rc or -beta tagged on.

For example:
https://wordpress.org/plugins/rest-api/
=>
https://downloads.wordpress.org/plugin/rest-api.2.0-beta15.zip

Granted, it's highly unlikely that we'll ever release one of our plugins with such a Stable Tag, and it's not super common across the repo: https://wpdirectory.net/search/01JDAFQMKVDE6ME17SH47V33D9

So I don't feel strongly about this.

Worst case in such a scenario is that the original URL ends up getting used without the version removed, which will likely still work (even if it has the even slighter possibility of downloading a stale version).

Thank you for pointing this out! I hadn’t considered the possibility of version tags like -rc or -beta. That’s an oversight on my part.

However, I believe the regex '#(\/plugin\/[^\/]+)\.\d.*.zip#' might not work as intended because it could capture the plugin name greedily. For instance, in the example provided, the download link might end up being https://downloads.wordpress.org/plugin/rest-api.2.zip instead of https://downloads.wordpress.org/plugin/rest-api.zip.

To address this, one solution could be to simply modify the regex to capture the plugin name non-greedily:

'#(\/plugin\/[^\/]+?)\.\d.*.zip#'

Alternatively, another approach would be to use the following regex:

'#(\/plugin\/[^\/]+)\.\d+\.\d+\.\d+(?:-\w+)?\.zip#'

This pattern accounts for optional tags like -rc or -beta and aligns with the regex used in the versions command, so it seems like a good choice to me.

Note in the example https://downloads.wordpress.org/plugin/rest-api.2.0-beta15.zip there is no patch version either, just a major and minor. So that would need to be optional as well.

This should address the greediness issue, by using \.\d.*?.zip instead of \.\d.*.zip:

$download_link = (string) preg_replace( '#(\/plugin\/[^\/]+)\.\d.*?.zip#', '$1.zip', $plugin_data['download_link'] );

Or rather, per #1693 (comment)

Stripping off everything up to the first . makes sense. However, I also noticed that some plugins have their download link as https://downloads.wordpress.org/plugin/<plugin-slug>.zip, particularly those with tags like trunk, such as https://downloads.wordpress.org/plugin/better-search-replace.zip.

Given this, I think we might need a regex like this:

$download_link = (string) preg_replace( '#(\/plugin\/[^\.]+).*\.zip#', '$1.zip', $plugin_data['download_link'] );

This should account for both cases where the version exists (like rest-api.2.0-beta15.zip) and where it doesn't (like better-search-replace.zip).

On second thought, can’t we just construct the download link directly from the slug in the $plugin_data as:

https://downloads.wordpress.org/plugin/<plugin-slug>.zip

This would simplify and remove the need for regex.

Hah. Good point.

I'm not a fan of regexing this from the download_link. Is there no externally controlled place (API responses or elsewhere) that exposes the format we want here?

Seeing comments like #1693 (comment) confirms my above concern: Using a regex for this is error-prone. Is there no way to get the actual URL from somewhere?

You’re right; relying on regex for this isn’t ideal. The plugins_api() function, when called with the plugin_information action, provides a versions field in the response that seems to include the URLs in the required format. Here's an example of the response:

{
    ...
    "versions": {
        "0.1.0": "https://downloads.wordpress.org/plugin/optimization-detective.0.1.0.zip",
        "0.1.1": "https://downloads.wordpress.org/plugin/optimization-detective.0.1.1.zip",
        ...
        "trunk": "https://downloads.wordpress.org/plugin/optimization-detective.zip"
    },
    ...
}

We could use the trunk key to get the required URL in most cases. However, there are scenarios where the trunk key doesn’t exist in the versions field. In those cases, the download_link itself is typically already in the desired format without a version or tag.

That said, implementing this approach would require making multiple API calls—one for each plugin—which again might not be ideal.

Don't we only need the plugin download URL if we actually want to download the plugin? I think making an extra request for that purpose makes sense. We shouldn't make all these requests for all the plugins when we cache the information. But for the moment when someone clicks "Activate" and we have to install that plugin, I think it's reasonable to make the request. I think that's even what WordPress Core does to install a plugin.

And even if the plugin also requires dependencies, making individual requests for these should not be an issue since realistically that shouldn't be more than 2-3 plugins.

This solution would be more reliable than us assuming things about the download URL and using a regex.

That makes sense to me.