`WP_VERSION` should default to latest patch if not provided

[schlessera]

Right now, if you provide the version as WP_VERSION=5.1, it will pull in WP version 5.1, even if 5.1.1 is available. This causes issues in tests that rely on the latest WP version, like the checks in the wp-cli/doctor-command.

It would make more sense for the WP_VERSION to behave more closely like semantic versioning.

So, if 5.1.2 would be the latest available version:

• WP_VERSION=5.1 => "use latest patch verison for the 5.1 minor version" => installs 5.1.2
• WP_VERSION=5.1.1 => "use exact patch version 5.1.1" => installs 5.1.1
• WP_VERSION=5.1.0 => "use exact patch version 5.1.0" => installs 5.1 (as that is the equivalent to 5.1.0.

This effectively means that all the WP_VERSION=x.x requests will always include all security patches and hotfixes.

[thelovekesh]

@schlessera Can you please assign this task to me?

[thelovekesh]

As discussed today during hack day,

To determine minor and patch versions we will need to rely on https://api.wordpress.org/core/stable-check/1.0/ to get the information on the released WordPress version, but as mentioned in wp-cli/core-command#108 (comment), this endpoint is not cached and result in slow responses or even rate limiting.

Since the wp-cli-tests package is widely used in CI for testing purposes, a high amount of calls to the API may cause rate limiting or worse API server might crash. To overcome this issue we will be saving version info as a JSON file in the repository itself which will be updated nightly using the GitHub actions workflow on the branch called artifacts.

cc/ @schlessera for visibility.

[thelovekesh]

Tasks

• Add workflow to fetch WP version data and save them to the artifacts branch.
• Update version resolving logic to include latest patch release.

[thelovekesh]

@schlessera Here is the PR to complete task 1 of above tasklist - #199.