The "--minor"-flag causes beta-releases to be installed

[deviationist]

Bug Report

• [x] Yes, I reviewed the contribution guidelines.
• [x] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

When I run wp plugin update {slug} --minor then beta-versions are considered for updating, while if I run wp plugin update {slug}or wp plugin update {slug} --patch then only stable releases are considered.

Not all plugins in the WordPress.org-repository have beta-versions tho. I'm currently working on a plugin called Servebolt Optimizer that uses beta-releases for testing and development purposes. You can find our releases here.

Describe how other contributors can replicate this bug

1. Set up a fresh WordPress install
2. Run wp plugin install servebolt-optimizer --version=3.2
3. Run wp plugin update servebolt-optimizer --dry-run and inspect that you are presented with a stable release
4. Run wp plugin update servebolt-optimizer --patch --dry-run and inspect that you are presented with a stable release
5. Run wp plugin update servebolt-optimizer --minor --dry-run and inspect that you are presented with a beta-release

Note: we're rapidly updating our plugins these days, and if we make a new stable release it will cause step 5 to return a stable version. In this case one might need to use a different plugin repository where the latest version is a non-stable release.

Describe what you would expect as the correct outcome

I would expect beta-versions and release candidates to be ignored by WP CLI unless being targeted specifically using the "--version"-argument.

Let us know what environment you are running this on

OS:	Darwin 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
Shell:	/bin/zsh
PHP binary:	/Applications/MAMP/bin/php/php8.0.8/bin/php
PHP version:	8.0.8
php.ini used:	/Applications/MAMP/bin/php/php8.0.8/conf/php.ini
MySQL binary:	/usr/local/opt/mysql-client/bin/mysql
MySQL version:	mysql  Ver 8.0.27 for macos11.6 on x86_64 (Homebrew)
SQL modes:
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/Users/user/code/wp-cli-bug-report
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version:	2.6.0

Provide a possible solution

PR with suggested fix can be seen here. Note that I was not able to add any tests because the plugin being used in the Behat-tests (WordPress Importer) does not have any beta or release candidates in the WordPress.org repository. I also considered to add a new argument to the command so that users could chose stable/beta/rc in terms of which tags/versions to consider during update.

[swissspidy]

BuddyPress also publishes pre-release versions to WordPress.org. We can add Behat tests using that plugin.

I would expect beta-versions and release candidates to be ignored by WP CLI unless being targeted specifically using the "--version"-argument.

We could also add a specific flag to allow / look for pre-release versions.

[wojsmol]

@swissspidy There is --version=dev https://github.com/wp-cli/extension-command/blob/6401d7ea51084fac40010c2fb305be640675f385/src/Plugin_Command.php#L601

[deviationist]

BuddyPress also publishes pre-release versions to WordPress.org. We can add Behat tests using that plugin.

I would expect beta-versions and release candidates to be ignored by WP CLI unless being targeted specifically using the "--version"-argument.

We could also add a specific flag to allow / look for pre-release versions.

Initially using Buddypress sounded like a good idea, but I'm having a hard time seeing how I'm supposed to write the Behat-test since I would need the latest release to be a beta or RC. When I add the "--minor"-flag then a different part of the code is running compared to when the "--version"-argument is present. This rules out using "--version=dev" during testing. When the "--version"-argument is present then I will not reach the code that iterates and compares versions (which I've changed in my PR). We can only reach this code by using "--minor" it seems.

I feel like unit tests would be a better alternative to actually test this, so that we could feed an array of plugin releases and see which one is considered as the highest release. We could then add a stable-restraint and inspect that beta/RC-releases are ignored. Using Behat I guess we would need to set up a dummy plugin where the latest release/tag is always a beta/RC.

Hopefully that made sense, if not then please let me know and I'll gladly elaborate. Thoughts?

[danielbachhuber]

@roberts91 Do you want to re-submit https://gist.github.com/danielbachhuber/20ad98877aff6e71d6ffc44151b61c25 ?

I'm fine to land it if existing tests pass. I think it will be difficult to contrive a feature test for this.

[planetahuevo]

Could this be related and fix this one at the same time? https://github.com/wp-cli/extension-command/issues/292

I am getting a fatal error running minor updates on plugins because of the dev and other versions.

[danielbachhuber]

I am getting a fatal error running minor updates on plugins because of the dev and other versions.

@planetahuevo Can you provide specific steps I can use right now to reproduce the error?

[planetahuevo]

I am getting a fatal error running minor updates on plugins because of the dev and other versions.

@planetahuevo Can you provide specific steps I can use right now to reproduce the error?

Everything is detailed on the issue #292 The steps are:

• WordPress installation with plugins and elementor plugin installed (not up to date).
• Run wp plugin update --all --patch --dry-run And you will get this error. PHP Fatal error: Uncaught UnexpectedValueException: Invalid version string "3.12.0-dev1" in phar:///RunCloud/Packages/RunCloudAgent/bin/wp-cli/vendor/composer/semver/src/VersionParser.php:186

[danielbachhuber]

@planetahuevo I don't think yours is quite the same issue, but I have a fix for it: https://github.com/wp-cli/extension-command/pull/354

[planetahuevo]

@danielbachhuber

@planetahuevo I don't think yours is quite the same issue, but I have a fix for it: #354

That is amazing. Thank you very much!! You made my day!

[danielbachhuber]

@planetahuevo Happy to help! The fix is now available in the nightly build (wp cli update --nightly), or you can wait until the next stable release.