WordPress Plugin releases: who needs a big bang anyway?

On January 1st Mika Epstein blogged about releasing/ updating software for large projects, advising against releasing software during the festive season;

With the increasing provenance of online stories and websites for everyone, pushing a change when we know that the majority of the world is celebrating something between Nov 15th and January 15th is reckless. […] picture what happens when an update has a small bug that takes down […] 1/1000 of 1/4th of the entire Internet. […] It may be time to call a year end moratorium on updates to our systems and apps.

Working in corporate IT myself I could only agree. In theory that is, because a couple of days before I had purposely pushed out a major Autoptimize release in the last week of December, on a Saturday. Why? While inching closer to Autoptimize 2.0’s release, I was becoming worried of the impact some of the bigger changes could have. Impact as in “what if this breaks half of the sites AO is installed on“. One way to limit such impact, I thought, is by releasing on a moment people are bound to be less busy with their websites. So by releasing on Boxing Day, I assumed less people were bound to see & install the update on day 0, limiting the damage a major bug could do.

Now I do agree this approach is very clumsy, but being able to limit the amount of people seeing/ installing a plugin (or theme) update on day 0 could help prevent disasters such as the ones that plagued for example Yoast SEO. The idea of “throttled releases” is not new, it already exists for Android apps, with Google allowing developers to flag an update for a “staged rollout:

You can release an app update to production using a staged roll-out, where you release an app update to a percentage of your users and increase the percentage over time. New and existing users are eligible to receive updates from staged roll-outs. […] During a staged roll-out, it’s a good idea to closely monitor crash reports and user feedback.

Pushing an update to a percentage of users and monitoring feedback, allowing you to catch problems without the risk of impacting your entire install base? I want that for my WordPress plugins! So how could we get that to work?

What if an extra header were included in readme.txt, e.g. an optional “throttled release” flag. With that flag set, the percentage of people seeing the update in their wp-admin screens would be low on day one and increasing every day, for example;

Day after release% of people seeing release in dashboard
day 05%
day 110%
day 220%
day 340%
day 480%
day 5100%

This could be accomplished by having https://api.wordpress.org/plugins/update-check/ (against which WordPress installs check for updates) “lie” about updates being available if the “throttled release”-flag is set by e.g. simply introducing randomness in plugins/update-check/;

$showupdate = false;
$randomness = mt_rand(1,40);
if ( ($throttledrelease === true) && ($datenow === $pluginreleasedate) && ($randomness < 2) ) { 
    $showupdate = true; 
    }

(The “magic” in above code is in the random value between 1 and 40 which has a 1 in 40 (or 2.5%) chance of being smaller than 2 (i.e. 1), so in 2.5% of requests $showupdate would be true. This translates to 5% of requesting WordPress instances per day, as there are checks for updates every 12h, so 2 per day. Obviously on $pluginreleasedate+1d the condition would change, with the random value having to be smaller than 3 (so being either 1 or 2, i.e. approx. 5% of cases X2 =10%), on +2d smaller than 5 (1, 2, 3 or 4 = 10% X 2 = 20%) and so on. This randomness-based approach allows for plugins/update-check not having to keep tabs of how many people saw/ did not see the update at a given date.)

This obviously is just a simplistic idea that does not take into account any of the smart stuff undoubtedly going on in plugins/update-check/ (such as caching, most likely), but I’m pretty sure the wordpress.org-people who are responsible for that code could implement something along these lines. And I do think this would very much be worth the trouble, as It would allow Yoast & other major plugins developers to release without the fear of breaking hundreds-of-thousands WordPress sites within a couple of hours. And I would not have to release on Boxing Day, leaving me and the users of my plugins the time to digest that Christmas-dinner peacefully. What’s not to like?

Blogpost updated (code example + explanation) on 13/01/2016 to reflect the fact that a WordPress instance checks for updates every 12 hours, which impacts the randomness.

3 thoughts on “WordPress Plugin releases: who needs a big bang anyway?

  1. Nathan Samson

    This approach (in current sense) obviously assumes that every site would only check once a day.

    If someone would check lets say up to N times a day, the chance that at least one of them returns the new version approaches 1 for large(ish) values of N (lets say every hour).
    With a chance of 20% (day 2), after 5 checks the chance of hitting a true is 2/3rd (not even counting the changes from the 2 days before) instead of the desired 20%.

    obviously instead of being random you could just take the (numeric form of) IP address, divide that by N (with N being number of days) and see if the value is smaller than days-running/N.
    Obviously this would mean that every update the same users are test pigs which they might not really like.

    Reply
    1. frank Post author

      WordPress automatically checks twice a day, so my logic needs some tweaking indeed. Changing the frequency of those automatic checks is possible, but would be pretty rare, so doing something with the IP-address is probably not needed :)

      Reply
  2. frank Post author

    I discussed this in the Advanced WordPress group on Facebook and the most interesting comments I got there is that for wordpress core a system of throttled releases is actually already in place. The logic behind it is a lot smarter then the randomness I described in my blogpost as well;

    In case you’re curious as to how this 1-in-128 is calculated, we take the first three characters of the md5 of the site’s URL and convert it to base 10. md5 is hexadecimal (base 16), so the three characters mean 4096 possibilities. It’s now serving sites where this base 10 number is 0 to 31.

    Just randomly serving an instruction every 128 requests wouldn’t work. We do it this way to ensure a site receives a consistent response with repeated API

    So yeah, I want THAT for plugins :-)

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *