coverage: 84.348% (+0.4%) from 83.99%
when pulling 6ae6870 on justlevine:feat/autoupdater
into 644ebb5 on wp-graphql:develop.

@justlevine very cool!

Will take a look 👀

PR is working and ready for feedback.

Of the remaining todos in the PR description:

• (Bonus) Explore reuse in semver-compatible extensions.

I'll be testing against wp-graphql-headless-login and wp-graphql-content-blocks to see how easy it is for them to reuse the classes for their own SemVer auto-updates. This might result in some tweaks to the hooks and signature visibility, but the logic should remain intact.

• (Bonus) Show Upgrade Notices from readme.txt

@jasonbahl this is your decision as to whether we do this in this PR or even at all.

(Bonus) Explore reuse in semver-compatible extensions.

Did a basic review against wp-graphql-headless-login:

• Using the new SemVer class to disable major extension autoupdates took ~15 LOC ✔️
• There is no good way to reuse the *ScreenLoader classes and the underlying UpdateChecker class. That said, there's no real reason for reuse vs extension-native code, since we're currently only displaying issues regarding possibly incompatible versions, and not a general Upgrade Notice or similar. Further, we can make the necessary extensibility changes iteratively, so I see no reason to hold up review/merge for this.

Marking ready for review.

Disable autoupdates example:

add_filter(
	'auto_update_plugin', 
	static function( $should_update, $plugin ) {
		// Bail early if the plugin is not the one we're looking for.
		if ( ! isset( $plugin->plugin ) || ! isset( $plugin->new_version) ||'wp-graphql-headless-login/wp-graphql-headless-login.php' !== $plugin->plugin ) {
			return $should_update;
		}

		// If autoupdates are already disabled we don't need to check further.
		if ( false === $should_update ) {
			return $should_update;
		}

		$new_version = sanitize_text_field( $plugin->new_version );
		if ( '' === $new_version ) {
			return $should_update;
		}

		// Check if it's a major release.
		$release_type = \WPGraphQL\Admin\Updates\SemVer::get_release_type( WPGRAPHQL_LOGIN_VERSION, $new_version );
		if ( 'major' === $release_type ) {
			return false;
		}

		return $should_update;
	},
	10,
	2
);

Plugins that use the Requires Plugins: wp-graphql or use WPGraphQL in the plugin name or description are detected with an Unknown version compatibility.

Correct me if I'm mistaken, but I just want to clarify that the recommendation for extension authors now would be to use all 3 headers. (i.e. we're not replacing "Requires Plugins: wp-graphql", but enhancing things with additional headers)

i.e. a current WPGraphQL Extension plugin that had the following header:

 * Requires Plugins: wp-graphql // This header is recognized by WordPress core, and used on some existing extensions

would adjust like so:

 * Requires Plugins: wp-graphql
 * Requires WPGraphQL: 1.30 // Adjust as needed
 * WPGraphQL tested up to: 1.30 // Adjust version as testing is confirmed

I ran this through various scenarios locally with WPGraphQL for ACF and overall I'm pretty happy with the experience. Very thorough and well thought out. I have some small adjustments I want to make to some of the language re: compatibility and recommended actions to take before updating, but other than that this is super solid and well tested. 🙌🏻

This will add a lot of confidence for users and maintainers as we navigate the future of releasing breaking changes.

Plugins that use the Requires Plugins: wp-graphql or use WPGraphQL in the plugin name or description are detected with an Unknown version compatibility.

Correct me if I'm mistaken, but I just want to clarify that the recommendation for extension authors now would be to use all 3 headers. (i.e. we're not replacing "Requires Plugins: wp-graphql", but enhancing things with additional headers)

Close, but not exactly. All 3 are optional and can be used independently, depending on what the extension author is trying to accomplish.

• Requires Plugins: wp-graphql - prevents an extension from being activated if WPGraphQL is not active, and prevents WPGraphQL from being deactivated if the extension is active.
  This would e.g. make sense for WPGraphQL IDE (that can't run at all without WPGraphQL) but you wouldnt want it for let's say CPT UI (or arguably for WPGraphQL for ACF) since you want to still be able to configure your types even if WPGraphQL is (temporarily) disabled.

• Requires WPGraphQL: 1.30 this sets a minimum version constraint, which must be matched for the extension to be activated.
  If WPGraphQL isnt active, the extension can still be activated (e.g. CPT UI above).

• WPGraphQL tested up to 1.30: This offers an extra level of reliability when upgrading, by allowing autoupdates for major WPGraphQL releases (e.g. requires 1.30, tested up to 3.5 ).
  If an extension is missing this header/it falls outside the incoming WPGraphQL version, autoupdates will be prevented for major releases, and the confirmation modal is shown before manually updating.

@justlevine I opened a PR to your branch here with some updates to the messaging: justlevine#3

Requires Plugins: wp-graphql - prevents an extension from being activated if WPGraphQL is not active, and prevents WPGraphQL from being deactivated if the extension is active.
This would e.g. make sense for WPGraphQL IDE (that can't run at all without WPGraphQL) but you wouldnt want it for let's say CPT UI (or arguably for WPGraphQL for ACF) since you want to still be able to configure your types even if WPGraphQL is (temporarily) disabled.

Ok, I get where you're going with this. WPGraphQL for ACF specifically does use some functions from WPGraphQL in the admin UI screens for configuring ACF Field Groups and Fields to show in the schema, so WPGraphQL really is required. There's likely some defensive programming to ensure the functions exist before calling them (I should probably double check 👀, but WPGraphQL really is required for it). . .but I get the spirit of the idea. Some plugins might be compatible with WPGraphQL but might not TRULY require it.

Requires WPGraphQL: 1.30 this sets a minimum version constraint, which must be matched for the extension to be activated.
If WPGraphQL isn't active, the extension can still be activated (e.g. CPT UI above).

👌🏻

WPGraphQL tested up to 1.30: This offers an extra level of reliability when upgrading, by allowing autoupdates for major WPGraphQL releases (e.g. requires 1.30, tested up to 3.5 ).
If an extension is missing this header/it falls outside the incoming WPGraphQL version, autoupdates will be prevented for major releases, and the confirmation modal is shown before manually updating.

Great summary! This will help document this feature for release. 🙌🏻

Code Climate has analyzed commit 6ae6870 and detected 12 issues on this pull request.

Here's the issue category breakdown:

View more on Code Climate.