wp-cli
Introduce --version=beta argument for updating to latest WordPress beta
Running wp core update --version=nightly now updates to 4.9 alpha, since core branched 4.8 a few days ago and trunk is now 4.9 alpha.
If the WordPress Beta Tester plugin is used and is set to Bleeding edge nightlies it sticks to 4.8-RC2-40868. It appears to do this by appending a _beta_tester=true flag on the update request (source).
It would be great if WP-CLI supported a version flag such as wp core update --version=beta which stuck to the current beta/RC in the same way that the beta tester plugins appears to.
Might be worth pinging Westi or Dion for clarification.
It would be great if WP-CLI supported a version flag such as
wp core update --version=betawhich stuck to the current beta/RC in the same way that the beta tester plugins appears to.
👍
It appears to do this by appending a _beta_tester=true flag on the update request
It's actually the -wp-beta-tester suffix for $wp_version, see mangle_wp_version().
Snippet from the API code:
if ( 0 === strpos( $version, $stable_branch ) ) {
$ver = "$stable_branch-latest";
} elseif ( 0 === strpos( $version, $dev_branch ) ) {
$ver = "$dev_branch-latest";
} elseif ( 'trunk' !== $dev_branch && false !== strpos( $version, '-wp-beta-tester' ) && 0 === strpos( $version, (string) ( (float) $dev_branch + 0.1 ) ) ) {
// Handle WordPress Beta Tester requests for bleeding-edge during release transitions. Don't provide a package for trunk if current development happens on a branch.
$ver = "$dev_branch-latest";
} else {
$ver = 'latest';
}
@johnbillion How should we handle release candidates? If you use --version=beta, would you expect to get a release candidate?
Agh, I cannot, for the life of me, figure out the proper URL to get a beta download offer. Any tips?
https://api.wordpress.org/core/version-check/1.7/?version=4.8.3-wp-beta-tester&php=7.0.22&locale=en_US&mysql=5.5.5&local_package=&blogs=1&users=1&multisite_enabled=0&initial_db_version=38590
This request only appears to include the nightly that we already have.
@danielbachhuber The API doesn't return beta/rc packages, only the nightlies.
The API doesn't return beta/rc packages, only the nightlies.
@ocean90 Oh. Is there any way to pragmatically fetch beta/rc packages (other than scraping HTML)?
If you use --version=beta, would you expect to get a release candidate?
Yeah I think beta in this context should include anything from beta onwards up until release.
AFAIK that's how the Beta Tester plugin works, but I haven't checked it in a while.
Since 2020-09-07 is ready: https://meta.trac.wordpress.org/ticket/5412#comment:12
WordPress 5.6 is expected to be released on 2020-12-08, the current RC version is 5.6-RC1-49694, but wp core download --version=5.6-RC1-49694 did not work, just wp core download --version=5.6-RC1 which is a previous version.
It is possible to implement --version=rc, --version=beta, as the API already supports?
It looks like the w.org API implementation in https://meta.trac.wordpress.org/ticket/5412 doesn't quite do what I was expecting. For example I expected to be able to request a beta or an RC and be served one even if the release has since gone stable. Without this, it's only possible to request a beta or RC during the beta or RC window.
Example: I'm on 6.4 and I want to update to 6.5 RC even though 6.5 is already out the door and had some patch releases. The w.org API isn't responding with an RC package, it's only responding with 6.5.2 stable: https://api.wordpress.org/core/version-check/1.7/?version=6.4.0&channel=rc . The pretend_releases URL query parameter can be added, but then that makes the API request redundant because if we know which RC or beta version we want then we could just request the URL directly.