Expose the bundled Gutenberg version in the core version-check API

[arthur791004]

There is currently no machine-readable source for "which Gutenberg plugin version corresponds to the bundled in WordPress X.Y". The only reference is the hand-maintained Versions in WordPress (​https://developer.wordpress.org/block-editor/contributors/versions-in-wordpress/) doc page.

This can be derived today, but only by a multi-step git dance: read gutenberg.sha from package.json at the WordPress release tag, fetch that commit from WordPress/gutenberg, and read version from its package.json.

For example,

• WordPress 7.0.0 → Gutenberg 22.6.0-rc.1 (a2a354cf)
• WordPress 7.1 → Gutenberg 23.6.0-rc.1 (ea285b45)

That's not something a running site or a plugin can do.

Since the SHA is already pinned at build time, the corresponding Gutenberg version could be resolved once during the release build and surfaced as a field in the https://api.wordpress.org/core/version-check/1.7/ response (including for the ?channel=beta track), e.g. gutenberg_version alongside the existing per-offer fields.

Use case: hosts and plugins that need to decide whether an installed Gutenberg plugin is older than what the running WordPress already ships, so they can avoid loading a downgrade. Today that requires hardcoding a WP-version → GB-version table and updating it manually every release, which silently goes stale.

[tyxla]

I think that would be helpful. I can see us needing this information when testing GB with various versions of WP (including betas/RCs) or when deciding what takes higher precedence (GB vs WP) in certain cases.

cc @desrosj - I believe we discussed having something like this during WCEU, but I don't think we touched on doing it in the version check WP.org API endpoint.

[wprashed]

Implementation Considerations:

1. Backwards Compatibility: Adding a gutenberg_version property to each item in the offers array of https://api.wordpress.org/core/version-check/1.7/ is fully backwards-compatible, as WordPress core's find_core_update() ignores unrecognized offer fields. Example proposed structure:

{
       "response": "upgrade",
       "download": "https://downloads.wordpress.org/release/wordpress-6.8.zip",
       "current": "6.8",
       "version": "6.8",
       "php_version": "7.2.24",
       "mysql_version": "5.5.5",
       "gutenberg_version": "20.1.0"
   }

Data Storage & Pipeline: Rather than resolving Git SHAs dynamically on incoming requests, the release packaging workflow can resolve the corresponding Gutenberg version (from package.json at release build time) and persist it directly in the core release metadata table alongside the minimum PHP/MySQL versions.

Core Runtime Constant (Complementary Idea): In addition to this API enhancement, it may also be worth opening a ticket on Core Trac to expose a constant/helper in WordPress core (e.g. WP_GUTENBERG_VERSION in wp-includes/version.php) so that running sites have an offline, zero-network way to inspect the bundled Gutenberg version of the currently active WordPress install.