[wp-meta] [Making WordPress.org] #5412: Add offers for 'release-candidate' and 'beta' to Core API version check

[Making WordPress.org]

#5412: Add offers for 'release-candidate' and 'beta' to Core API version check
-------------------------+---------------------
 Reporter:  afragen      |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:
Component:  API          |  Resolution:
 Keywords:               |
-------------------------+---------------------

Comment (by 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.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5412#comment:2>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org