Update WordPress minimum version requirement to 6.9

[galatanovidiu]

The MCP Adapter depends on the Abilities API, which is only available in WordPress 6.9 or later. The current minimum version requirement is set to 6.8, which is incorrect.

[justlevine]

What about Woo and other projects that prematurely tried to backport support to 6.8?

With all the issues being caused by their use of Composer, I'd hate to give them any additional reasons to stick with that antipattern.
Keeping things (for now) at 6.8 and a check for wp_register_ability() will allow them and other to use MCP Adapter as a plugin.

[galatanovidiu]

Thanks for the feedback @justlevine!

You raise a valid point about adoption, but I think we need to be accurate about what actually works:

The distinction is important:

1. As a Composer package: Plugins using mcp-adapter as a dependency can still support WP < 6.9 by including wordpress/abilities-api as a Composer dependency.

2. As a standalone plugin: This will not work on WP < 6.9 because wp_register_ability() and other Abilities API functions don't exist in core. The plugin would fail immediately.

Keeping 6.8 as the minimum when the plugin cannot function on 6.8 sets users up for failure. A runtime check for wp_register_ability() would just result in the plugin doing nothing silently, not a great user experience.

For projects like WooCommerce concerned about backward compatibility: they would use mcp-adapter as a Composer package anyway, and can include the abilities-api package to support older WP versions.

The Requires at least header in the plugin file is specifically for the plugin installation scenario, and for that, 6.9 is the accurate minimum.

[justlevine]

For projects like WooCommerce concerned about backward compatibility: they would use mcp-adapter as a Composer package anyway, and can include the abilities-api package to support older WP versions.

That's what I'm trying to fix. They should not include MCP Adapter as a Composer library (if the GH issues here and downstream/cross-plugin weren't testament enough). However even once this is released on .org they and others will be forced to still use the Composer antipattern.

Keeping 6.8 as the minimum when the plugin cannot function on 6.8 sets users up for failure. A runtime check for wp_register_ability() would just result in the plugin doing nothing silently, not a great user experience.

Not sure why you think this, the ecosystem solved this part of plugin management years ago. Psuedocode from my phone:

protected function has_deps():bool {
  if ( function_exists( 'wp_register_ability' ) ) {
    return true;
  }

  foreach( [ 'admin_notice', 'network_admin_notice' ] as $hook ) {
    wp_admin_notice( __( 'MCP Adapter requires the WordPress Abilities API to work. Please either update to WP 6.9,  or ensure the Abilities API is installed as either a <a>Feature Plugin</a> or a <a>Composer dependency</a>', 'mcp-adapter' ), [...] );
  }

  return false;
}

Main::load_plugin() : void {
  if ( ! $this->has_deps() ) { return; }

  ... load our plugin classes
 }

Personally I dont think anything about the above is bad UX/DX, but either way I hope you can agree it's better DX than either:

• Plugin X has critical bugs that were fixed in MCP Adapter but are on a different release cadence
• Plugin X and Y are bundling different / conflicting versions of MCP Adapter

and a handful of other back/forward compatibility issues.