Nacin just tweeted about a little changeset in WordPress trunk that will delete all transients after an upgrade.
Obviously someone is going to make this “controversial”, there always is with a huge project like this; I’m also not looking forward to the wp-hackers thread on the topic either. Personally, I think it’s a good idea because it’s starts a new conversation about how to properly use transients and what a developer can expect from them. It could lead to some performance improvements on sites that had/have plugins/themes that improperly utilize transients, as suggested by Nacin already.
The problem, which I should preface is untested but conceptually reasonable to bring up, is upgrade/update lag.
I believe a lot of developers, myself included are hooking on init to check for a transient and if not available call an external API (and store it temporarily again). In a current project I’m doing this (technically hooking on admin_init to check on transient data) at least twice, one for an API callback and another to get a json package for an add-on marketplace. That said, immediately after an upgrade these external APIs are going to be hit because transient data isn’t available. This would ultimately delay the load of the next page, which for any user would be either: the welcome page (that the user is redirected to after an auto-upgrade) or the dashboard (redirected to after the DB update page when first visiting the admin after core was updated manually (SVN/Git)).
Consider I do a poor job maintaining these external resources and they’re slow to respond or worse timeout, that would mean a user who just upgraded would be staring at a white screen for the duration that it takes for these external APIs to respond. In the perception this WP user/admin, the burden for this delay wouldn’t be on the plugin authors or external resources it would be on WordPress. Most likely causing people to think ‘is it going to take this long every-time I upgrade?’.
There are a lot of other
rabbit holes issues that could be brought up but this is the one I’m concerned about because it affects the perception of how easy an upgrade is.
Do I still think it’s worth clearing out transients after an upgrade? Absolutely. The approach should be different, possibly a background process after the welcome page (or dashboard).
[Update] Anyone know if after an upgrade/update (with these changes) update_plugins and update_themes are fired, since their transients are deleted? This would cause our project (as an example) to need two more immediate external fetches by filtering pre_set_site_transient_update_plugins and pre_set_site_transient_update_themes, excluding the calls to the extend API which I’d expect to always be fast.