Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add core release command #109

Closed
wants to merge 7,605 commits into from
Closed

Add core release command #109

wants to merge 7,605 commits into from

Conversation

schlessera
Copy link
Member

Adds retrieval of available releases from the wordpress.org API server.

Version constraints are interpreted in the following way right now:

  • 4 => anything that starts with the major version 4. This would mean >= 4.0.0 && < 5.0.0.
  • 4.8 => anything that starts with the major version 4 and minor version 8. This would mean >= 4.8.0 && < 4.9.0

Some notes:

  • Patch, pre-release or build constraints are not supported yet, as the API server does not provide querying functionality for these.
  • I initially added a --locale flag, but removed it again for now, as the API server does not seem to respect it for all results, only for the very latest version.

Fixes #108

danielbachhuber and others added 30 commits April 18, 2017 05:04
Abstract `wp core verify-checksums` to wp-cli/checksum-command
Run Travis tests against WP-CLI dev-master
Fix Travis CI caching for composer
For PHP 7.1 compat use get_wp_details() instead of "version.php" include.
Use {WP_VERSION-latest} vars to avoid needing to update tests on WP releases.
Clarify this command as a bundled command
Copy link
Member

@thrijith thrijith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@schlessera Can you please merge latest master here, for CS changes?

@chesio
Copy link

chesio commented Aug 26, 2019

I would suggest to update example output to include WordPress 5.2 release as well - with an actual change in required PHP version it would make the examples even more telling.

Copy link
Member

@thrijith thrijith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only minor query, rest LGTM.

$response = Utils\http_request( 'GET', $url );

if ( strncmp( (string) $response->status_code, '2', 1 ) ) {
WP_CLI::error(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we avoid usage of sprintf?

$semver_regex = '/^v?(\d+)(?:\.(\d+))?(?:\.(\d+))?(?:-([0-9A-Z-.]+))?(?:\+([0-9A-Z-.]+)?)?$/i';

if ( ! preg_match( $semver_regex, $version, $matches ) ) {
WP_CLI::error(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

@thrijith
Copy link
Member

thrijith commented Oct 2, 2019

Also as @chesio mentioned, an example of 5.2 would be a good.

@nylen
Copy link
Contributor

nylen commented Oct 15, 2019

Shouldn't this be called releases instead?

@schlessera
Copy link
Member Author

Shouldn't this be called releases instead?

I think the "resource" we're dealing with here is "a release", and you can fetch a list of multiples of this resource. Just as we have plugin, post or option as singular resource names.

For context, the main use case I have for this is to turn a generic "release to use for tests" into "the latest release matching this criteria to use for tests".

So, if I state that I want to run tests with 4.9, I don't want to fetch 4.9.0, but rather the latest bugfix release of the 4.9 branch.
(see wp-cli/wp-cli-tests#51)

@schlessera
Copy link
Member Author

BTW, this is still unmerged because the endpoint I'm using doesn't provide everything I need and I'm not sure I'm using the correct endpoint in the first place (see #108 for more details).

@nylen
Copy link
Contributor

nylen commented Oct 15, 2019

I think the "resource" we're dealing with here is "a release", and you can fetch a list of multiples of this resource. Just as we have plugin, post or option as singular resource names.

I'm not sure the same principle applies - all the other examples have multiple subcommands, and in that case it should be wp core release list.

When I read core release I thought of release as a verb, and thought: "Why would someone use WP-CLI to do a core release?"

@nylen
Copy link
Contributor

nylen commented Oct 15, 2019

For context, the main use case I have for this is to turn a generic "release to use for tests" into "the latest release matching this criteria to use for tests".

It seems like there are 2 uses cases then: listing all releases (optionally matching some criteria), or finding the latest release (optionally matching some criteria).

Tying back into the "resource" discussion, why not make this into a proper resource with appropriate subcommands for these cases? For example:

wp release list
wp release list --version=4.9
wp release latest
wp release latest --version=4.9

Using --version as a partial match also seems a bit off, since a version should point to a specific release. Maybe this should be --branch or --series instead?

@danielbachhuber
Copy link
Member

Proceeding with wp-cli/wp-cli#5594 for this repository. I've captured this PR to https://gist.github.com/danielbachhuber/c3f452c41ae22532df1123550fec5f84 in case this PR is auto-closed or broken in some way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add core release command(s) to fetch available releases through the .org API