[wp-meta] [Making WordPress.org] #3474: Introduce `serve-happy` API endpoint

[Making WordPress.org]

#3474: Introduce `serve-happy` API endpoint
--------------------------------------+-----------------------
 Reporter:  flixos90                  |       Owner:  dd32
     Type:  task                      |      Status:  accepted
 Priority:  normal                    |   Milestone:
Component:  API                       |  Resolution:
 Keywords:  has-patch has-unit-tests  |
--------------------------------------+-----------------------
Changes (by dd32):

 * owner:   => dd32
 * status:  new => accepted


Comment:

 I'll take a deeper look into this tomorrow, however, as a few initial
 notes:
  - Returning `latest_php` probably isn't going to be useful to the
 implementation, nor actually be updated as often as PHP releases are made,
 so it's probably worth dropping that field entirely. BrowseHappy the
 website IIRC pulls the data from another source, which I don't think we'd
 want to implement in an API.
  - Can we cache the API endpoint responses based on the `REQUEST_URI`
 alone? (If possible, reliance upon `$_POST` and `$_SERVER` vars means
 caching isn't really viable) At present it appears as such.
  - How is it planned for the `upgrade_url` parameter passed to be host-
 specific? What data would be used?
  - Including the URL to `https://wordpress.org/support/upgrade-php/` seems
 like a worthwhile idea at first, although having it hard-coded in core
 would allow for locales to translate it into their own languages - which
 makes it seem far more important

 To clarify:
 > Return true/false for whether the passed PHP version needs to be
 upgraded.
 The `'upgrade'` flag isn't whether it needs upgrading, but if
 WordPress.org believes it's `out-of-date`. Calling it `upgrade` seems like
 a misnomer, It's not "Oh you're running 7.0.1, so you need to upgrade to
 7.0.27".

 Two options I thought of while looking at it:
  1. Combine to single field, `status` => `out_of_date,
 no_security_updates, ok, latest` (`ok` is a bit of a random 'status' here,
 `latest` could be combined into it too)
  1. Rename to more verbose flags such as (for PHP 5.2) `out_of_date` =>
 `true` & `receiving_security_updates` => `false`

 I think we're okay to assume that PHP will retain it's [http://php.net
 /supported-versions.php supported versions security deprecation] schedule
 for 7.x, but I question if it'll stay that way come `8.0`, having a
 `insecure_php <= 5.6` might not work too good in a far distant future, one
 we can cross when we get there (and lets ignore that Dec 3rd -> 31st
 window where 5.6 gets updates, but 7.0 doesn't :) )

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