In reply to David Anderson.

David, you make a good point. WordPress.org while saying the wrong thing - "update to our latest beta all the time" as the current release is effectively beta software as both the 4.7 and 4.8 releases have demonstrated - actually does the right thing - maintaining security releases going back to 3.7.x (deprecating all releases pre-3.9 or even 4.0 would seem fair at this point). WordPress's security czar Aaron D. Campbell told me at WCEU Paris that the security team would like to drop updates for a few of the trailing releases to reduce the burden.

It would be really great if the WordPress plugins team could add a lightweight flag for security releases by plugin authors. For instance it might be that version 2.7.3 of a plugin is secure but 3.0.x to 3.1.2 are not (additional functionality). The issues is with self-policing. Those freemium plugin authors who create exclusively for money (I won't list them this time as I'd like you to see this answer) will be tempted to mark everything except the latest release as insecure. There are ways to enforce less selfish behaviour from freemium/pro authors like temporary suspensions from plugin directory search for false alarms (just like for pulling a fire alarm when there's no fire).

It also would suggest that plugin authors should be able to release security fixes for a previous major release. I.e. if I were the author of the plugin above and I knew that I had a security fix for 2.7.2 which is easy to implement and that many of my users were still on 2.x family instead of 3.x for compatibility reasons, I'd be able to release a 2.7.3 version.

Significant structural enhancement to the WordPress plugins space like this would have been more welcome than an almost year long tug of war over a mobile style appstore layout for the plugin directory - which finally had to be largely retired as it just made the plugin browsing experience worse.

Even as matters stand, for a site owner or an agency who would like to reduce his/her maintenance burden, managing one's updates in a controlled way can reduce that maintenance burden by a factor of four. Avoiding plugins with a history of acute security issues is a good start. Locking down your hosting to minimal required permissions to run WordPress is another good step (WordPress managed hosts do a good job with this if a site owner or an agency don't have the scale to manage hosting themselves).

Both Sucuri and WordFence weblogs (and often WP Tavern and ManageWP) cover almost all security vulnerabilities in layman's terms (unlike say CVEdetails). There's even an aggregate WordPress security blogs feed. If a WordPress site's main admin (that might be the publisher) picks one of them to read regularly, s/he'll know if they face any security issues with existing plugins. Reading occasional security bulletins is a lot less work than diagnosing software conflicts.

In any case, the current situation of whack-a-mole between buggy core releases (really they are beta and should be embraced by cutting edge types and mature for six months before being declared production) and incompatible or paid upgrades to plugins is anything except efficient or professional.

Working graphic designers and busy video production houses never run the latest version of their OS as they need stability to do their work. I'd say business and media publishers or just a guy/woman who want to publish regularly are no different. Let's work together to make publishers/site owners jobs easier, not harder. Many of us joined the WordPress community to help democratise publishing and help people create more and better content. Let's do just that instead of draining them with never ending "mandatory" software updates.

Bringing the conversation back to WP Rollback - not all the necessary tools are in WordPress but it's really great that companies like WordImpress are creating software to improve updates workflow with the existing tools which are there but not easily accessible.