Incorrect version for specific plugin

[strarsis]

The bbPress Notify (No-Spam) plugin has 2.18.2 as current version (at time of writing).
On wpackagist its latest version is listed with 2.27.7.
When updating to that version, the installed plugin is listed with version 2.17.7 instead.

[NoelLH]

It looks like something has been done inconsistently at package level such that Subversion and the package database don't match. On the WordPress plugin page itself you can see the phantom version in the dropdown at the bottom: https://wordpress.org/plugins/bbpress-notify-nospam/advanced/

[strarsis]

@NoelLH: Thanks for investigating this! This kind of issue occurred with other plugins, too: Some higher version that is not even listed on the plugin directory page. Is this then a bug of WordPress plugin directory, that it should enforce those version tags more?

ISimilar issue with WooCommerce plugin: https://discourse.roots.io/t/403-error-in-wordpress-woocommerce-admin-with-multiple-sites-rest-cookie-invalid-nonce-cookie-check-failed-api-fetch-wp-json/26524/5?u=strarsis)

[NoelLH]

@NoelLH: Thanks for investigating this! This kind of issue occurred with other plugins, too: Some higher version that is not even listed on the plugin directory page. Is this then a bug of WordPress plugin directory, that it should enforce those version tags more?

ISimilar issue with WooCommerce plugin: https://discourse.roots.io/t/403-error-in-wordpress-woocommerce-admin-with-multiple-sites-rest-cookie-invalid-nonce-cookie-check-failed-api-fetch-wp-json/26524/5?u=strarsis)

I think they would probably categorise it as a design limitation, since code probably has to get to the Subversion (svn) server before it can be considered for having metadata added to the package releases database. But it certainly results in a buggy situation if a version is partially pulled in this way without being taken off svn.

I don't know what a fix would look like that doesn't break backwards compatibility on the WordPress side.

Similarly, I think Wpackagist is in a tricky spot when things like this happen. If it aggressively removed versions that are still in svn but aren't [any more] formally listed release versions, then that could create avoidable breaks for anyone who already updated and has the removed version in their lockfile. There's an argument that it's better to break on install than to allow installing disavowed versions, but it would represent a big change in behaviour and could stop Wpackagist being suitable for certain deployment strategies that use Composer lockfiles but not completely built artefacts with WP packages baked in.