Add offers for 'release-candidate' and 'beta' to Core API version check

[afragen]

Core API version check at ​https://api.wordpress.org/core/version-check/1.7/?version=5.7-wp-beta-tester displays offers for development, latest, and autoupdate.

In a recent thread in #core-committers @matt asked if there was an easy way to flag auto-updates for release candidates and stable, but not beta or alpha. ​https://wordpress.slack.com/archives/C18723MQ8/p1599065974000500

If there were Core API offers for release-candidate and beta, in addition to the currently used development, I believe it would be possible to more easily modify the WordPress Beta Tester plugin to select these streams. Currently the Beta Tester plugin does a lot of manipulation to set updating to a beta or RC release. Most of this work by @pbiron.

For beta the download should display the current or next (potential) beta release. For RC the download should display the current or next (potential) RC release.

Currently the Beta Tester plugin determines which is the next available beta/RC by checking for a 200 response to the standardized download links.

I think adapting the API and the Beta Tester plugin will likely yield the simplest implementation.

Obviously the API offer would change depending on the query passed.

[dd32]

For beta the download should display the current or next (potential) beta release. For RC the download should display the current or next (potential) RC release.

Currently WordPress.org has no knowledge of release cycles, and all the API data is based upon file existence on the filesystem.
While we could add a way to flag "There's going to be a Beta release on Dec 1st" it feels like that's just another piece of data that's going to add to the burden on making releases.

Perhaps this IS something we should add, so that the Beta Tester plugin can have some kind of countdown / upcoming releases section.. but I do wonder if the updates api is the right place for that information.

After reading the slack thread, I think we can safely ignore the beta tester plugin here for a moment, whatever we do will affect it, but it's a different use-case than what's proposed.

What's proposed in slack, is a way for Core (by itself) opt-in to Beta/RC releases.

Normally, I'd say that we want people to be running the Beta/RC nightly during that timeframe, but, when it's core and not the beta-tester plugin doing it, just the exact Beta/RC releases is probably enough updates.

What I think we should do, is have ​https://api.wordpress.org/core/version-check/1.7/?version=5.5.1 return something like this:

[
   { response: beta, version: 5.6-beta1, ...},
   { response: latest, version: 5.5.1, ...},
]

or

[
   { response: release-candidate, version: 5.6-RC1, ...},
   { response: latest, version: 5.5.1, ...},
]

or even a minor releases RC:

[
   { response: release-candidate, version: 5.5.1-RC1, ...},
   { response: latest, version: 5.5.1, ...},
]

and having those returned for all version=5.5 requests (version gate it on the requested version being >= 5.6-alpha to avoid back-compat issues with older WPs)

Core can then choose to use that beta/release-candidate update response instead of the latest response if it's been opt'd in.

[dd32]

I think we can safely ignore the beta tester plugin here for a moment

Just to jump back to this, I suspect, that any changes here won't affect the beta testing plugin significantly - it'll shift some of the logic from the plugin to core, some to the api, but it'll still have a lot of cludge.

We can improve the API for the beta tester plugin - but part of the problem we have right now is that the way it signals the API is through the version field rather than adding an additional query arg.

Perhaps a first step is for the beta testing plugin to add a flag to the api request (instead of just changing the version) to signal that it's installed and that it wants a development response instead of just the stable responses?

[afragen]

@dd32 if you let me know what query arg you’d like the plugin to send we could add it pretty simply. (Famous last words)

As far as the updates API only seeing files on the filesystem, couldn’t it create the beta or RC based on the existence of the actual release. Of course this would only show a download during the release party after it’s created.

[dd32]

if you let me know what query arg you’d like the plugin to send we could add it pretty simply. (Famous last words)

Anything, that makes sense for core to maybe also use one day? I wasn't sure what it should be called so I didn't make a suggestion..

As far as the updates API only seeing files on the filesystem, couldn’t it create the beta or RC based on the existence of the actual release. Of course this would only show a download during the release party after it’s created.

Yup, that's my thought - We'd be basing it on the existence of the file on disk, which is once it's packaged. We also store the $wp_version for each of the packages built (plus the nightlies).
The original suggestion was should display the current or next (potential) beta release so I was thinking you meant "potential next beta, ie Beta1 released next Wednesday" rather than the Beta that would 'officially' be released in a few minutes once the release party is over.

[afragen]

I think we're on the same page re: updating the API response AFTER the beta or RC release.

I envision something like adding a query arg as follows.

beta-RC returns a download package with the highest release of a beta or the highest release of release candidate if that is available.

release-candidate returns a download package with the highest release of a release candidate if that is available.

When the next stable release happens the download package should return that. As the user would still be on a development branch when the next beta or RC happens after a stable release the user would then see an update to that next releases beta or RC.

If the user is not on a development release or the specific query arg is not present nothing changes.

Does that make sense?

[dd32]

@afragen I've done some API work as an experiment, but I'm not going to deploy it late on a Friday :)

I was thinking of.. introducing a channel parameter which accepts stable (default), development (default for >= $current_release), branch-development, beta and rc.
When using that parameter, no $wp_version mangling should be used.

Description:

• stable: Only stable releases.
• development: Trunk nightlies (ie. trunk or 5.7-alpha when 5.5.x is stable and 5.6-RC3 is latest RC)
• branch-development: Nightlies of the current branch - 5.5.2-alpha right now
• beta: X.Y.Z+1 Beta/RCs, X.Y+1 Beta/RCs
• rc: X.Y.Z+1 RCs, X.Y+1 RCs

Example requests and what action it'd do:

• channel=beta&version=5.5.1 will return the beta/RC/stable when added. ie. 5.5.2-RC1, 5.6-beta1, 5.5.2, 5.6
• channel=rc&version=5.5.1 will return the RC/stable when added. ie. 5.5.2-RC1, 5.6-RC1, 5.5.2, 5.6
• channel=development&version=5.5.1 will push it to trunk nightlies ie. 5.6-alpha
• channel=branch-development&version=5.5.1 will push it to nightly releases of 5.5.2-alpha
• channel=branch-development&version=5.4 will also go to 5.5.2-alpha, rather than sticking on the old branch

When I deploy it, I'll include a parameter to simulate extra releases being made (ie. the API returns a response believing that 5.6-RC1 has been released when it hasn't) for initial testing and the intention to remove it after a bit..

Does that sound reasonable to you?

[afragen]

@dd32 I think the above proposal is inspired.

Just making sure that channel=stable is optional too.

[dd32]

Replying to afragen:

Just making sure that channel=stable is optional too.

Yes! Optional parameters, but if not specified the "channel" is assumed based on the parameters (Which for most people, will be stable - or development if running on trunk). It's basically consolidating the various decisions the API currently makes into a singular label which can be set from the client instead of the API just guessing what the client wants.

For testing (and maybe even ongoing..) I'll include a response header that indicates what the channel it's using is, so you can verify it's behaving as expected (open-sourcing this specific API isn't straight forward, so I'm not attempting that right now, but wanted to make it more transparent)

[afragen]

@dd32 I think I've gotten a branch of the Beta Tester plugin ready to test.

[afragen]

Similarly asked #4767

[dd32]

@afragen I've deployed my changes.

If I'm not around and this broke something, revert r16453-dotorg (for those who have access :) )

​https://github.com/WordPress/wordpress-develop/pull/520 is an example of a core change we could make to allow WP_AUTO_UPDATE_CORE to be set to rc or beta.

As I mentioned, I've included a parameter to simulate releases (only Beta/RC releases!)

• Running WP 5.5.1, want RC updates, and 5.6-beta1 has been released. should return latest: ​https://api.wordpress.org/core/version-check/1.7/?version=5.5.1&channel=rc&pretend_releases[]=5.6-beta1
• Running WP 5.5.1, want beta/RC updates, and 5.6-beta1 has been released. should return development and beta1: ​https://api.wordpress.org/core/version-check/1.7/?version=5.5.1&channel=beta&pretend_releases[]=5.6-beta1
• Running WP 5.5.1, want beta/RC updates, and 5.6-beta1/RC2 have been released. should return development & RC2: ​https://api.wordpress.org/core/version-check/1.7/?version=5.5.1&channel=beta&pretend_releases[]=5.6-beta1&pretend_releases[]=5.6-RC2
• Running WP 5.4, want beta/RC updates, and 5.5.1 has been released. should return upgrade & 5.5.1: ​https://api.wordpress.org/core/version-check/1.7/?version=5.4&channel=beta

You can look at the X-Update-Channel to see what it's determined a request to be, you should be able to look at the existing Beta Tester responses to see that too.

[afragen]

@dd32 I've updated a branch of the Beta Tester plugin to work with these changes. Still testing but I have to say the new API responses work just as I expected.

Thank you so much.

[dd32]

I've opened ​#core51319 for the possible WP_AUTO_UPDATE_CORE change.

I'm going to close this as fixed for now, please re-open if issues occur.