Long-term plan for handling Gutenberg version compatibility with core

[iCaleb]

There's now a fairly common precedent that new major WP releases are often incompatible with many prior versions of Gutenberg. This makes sense, given that more and more we're going to see GB tie into the WordPress core experience. However there are some problems with how this version dependency / relationship is currently treated.

In #59718 this is explained some. But to briefly re-iterate:

1) Currently, when a traditional WP upgrade is triggered and files are being replaced, core will also decide if it should deactivate the Gutenberg plugin based on the plugin version, [seen here](​https://github.com/WordPress/wordpress-develop/blob/32f75bf0f4c9adeaa51277f979490a53bea07e4f/src/wp-admin/includes/update-core.php#L1842-L1868).

2) This brings about some issues. Two in particular come to mind:

• If the Gutenberg plugin is not db-activated, but rather code activated, it will not be deactivated and the WP upgrade will cause the site to fatal error. An example of this is if GB is being loaded as an MU Plugin.

• Even if the GB plugin is db-activated, it's fairly common for applications to be managed via version control. Meaning the _upgrade_core_deactivate_incompatible_plugins routine isn't actually being called. So the newly updated core files are essentially instantly present on an application that never got the chance to deactivate the older version of GB.

So I wanted to open up this ticket for some discussion on how we could make this better, and perhaps prioritize for the next major release so we can stop risking fatal errors due to this during WP upgrades :)

---

Ideas:

The first thing that came to mind is how the Action Scheduler plugin/library works. Many different plugins can load in this library, or it can be added as a standalone plugin. Each instance will register itself, but then it will only initialize one version ([the latest](​https://github.com/woocommerce/action-scheduler/blob/trunk/action-scheduler.php#L36)). This helps prevent duplicate class/function name fatal errors, and makes the loading process safe and easy.

Gutenberg is perhaps an even simpler use case, in that there's just two pieces - there is the standalone plugin and there is core. And rather conveniently, core is able to intercede early on in the process and register some loading rules before any plugins get a chance to load in.

A quick code example could be something like this inside the GB plugin:

<?php

// https://github.com/WordPress/gutenberg/blob/187224a67b839ace8e9c42b85f351fda996a2361/gutenberg.php#L72
function gutenberg_pre_init() {
        global $wp_core_minimum_allowed_gutenberg_version;
        $current_gutenberg_version = '16.4';

        if ( version_compare( $current_gutenberg_version, $wp_core_minimum_allowed_gutenberg_version, '<' ) ) {
                // Add some UI messaging to explain that the plugin isn't truly being loaded.
                return;
        }

        // Load the plugin.
        require_once __DIR__ . '/lib/load.php';
}

In this example, WP core would be responsible for declaring $wp_core_minimum_allowed_gutenberg_version. This will help ensure that the conflicts between older versions of GB and WP core can truly be avoided.

Notably, it'll be important to think this through and make sure we give core all the controls it will need to influence the loading of the GB plugin. It's not really enough to rely on every GB plugin version to set these things and know it's future compatibility status.

I was recently was pointed towards this PR which looks like a great start: ​https://github.com/WordPress/gutenberg/pull/35194. Although I would probably opt towards leaving something like GUTENBERG_MAX_WP_VERSION to always be defined by WP core since that is where we'll have the best context and the ability to alter it before a release.