[wp-meta] [Making WordPress.org] #4767: Add beta/RC offers to core version API check

[Making WordPress.org]

#4767: Add beta/RC offers to core version API check
--------------------------------------+---------------------
 Reporter:  afragen                   |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:
Component:  API                       |  Resolution:
 Keywords:  dev-feedback 2nd-opinion  |
--------------------------------------+---------------------

Comment (by dd32):

 Replying to [comment:5 pbiron]:
 > Being able to just click "Update Now" on the "WordPress Updates" screen
 would greatly increase the pool of people able to test the packages prior
 to release.

 That's a good point, often that all happens before the nightlies are
 updated. "Fun" fact - The Beta/RC packages are never exposed by the update
 api's, only nightlies, that's part of what makes it hard to expose
 Beta/RC's directly. That also means that we'd be "releasing" the Beta/RC
 packages before it's actually intended to be released.


 >I install a beta/RC on a site and begin in-depth testing.  I find
 something that doesn't appear to work correctly but it's not easy to
 figure out why and so it will take a few days to really dig in and
 investigate.  When I do get back to it I can't reproduce what I thought
 was a problem and I spend considerable time trying to determine whether
 the problem disappeared because it was "data dependant"

 That is more about automatic updates than Beta/RC vs Beta/RC+Nightlies
 inbetween.
 The scenario you describe would also happen if you didn't get back to it
 until after the next Beta/RC - which could be as long as a few weeks or as
 short as two days.

 The other side of it, is that a user doesn't run into that problem in the
 first place, as they install Beta1+1 day which had fixed it ahead of them
 running into it.

 It varies between releases, but I've seen lots of "annoying" bugs in my
 time that exist in Beta1/2 that get reported a lot with the same response
 of "Update to the nightly, or wait for Beta X+1 to be released next week"
 being given multiple times a day to affected users.

 One initial thought that could help with your specific situation is
 Beta/RC's having a "living" changelog - A log of recent changes made since
 Beta1, a list of "known problems" (Defects that are still open on the
 milestone) - for developers who are testing the beta/rc to refer to.


 Replying to [comment:7 pbiron]:
 > My thinking on what the change to the API would look like is: it would
 take an extra parameter (e.g., `?beta-rc=true`) to cause it to return
 beta/RC package download URLs in the `development` and `autoupdate` offers
 and to **not** return those offers if, based on the `?version=` param, the
 next beta/RC isn't available.

 That's mostly exactly what I was thinking, `?testing=beta` and
 `?testing=rc` and only returning `>= $version+0.1-Beta` or `>=
 $version+0.1-RC`.
 It would even be possible to return these along-side the "current"
 version, so that the end-user had the option to install it through their
 Updates dashboard or not (ie. autoupdates disabled for next-branch, but
 keep getting their current branch automatic updates)

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