WordPress update policy/philosophy?

WordPress is developed by many talented and eager volunteers. As soon as a release is finished, work begins on the next. Sometimes it’s new features, sometimes it’s a maintenance-focussed released, but it’s always done in view of the public via https://make.www.ads-software.com/ and mostly on https://make.www.ads-software.com/core/ with public participation encouraged, and always done to make WordPress a better CMS.

We aspire to release three major versions a year because, through trial and error, we’ve found that to be a good balance between getting cool stuff in each release, but not too much that we end up breaking more than we add.

From: https://make.www.ads-software.com/core/handbook/about/philosophies/#deadlines-are-not-arbitrary

Releases land in public Beta usually a month before the first public Release Candidate, and those last until all of the bugs are ironed out. Those are publicly available, and all plugins and theme developers are encouraged to test their products again them before the file release lands (no sooner than a month after the first public Beta). If you manage particularly huge/complex sites, it’s generally recommended that you keep a staging copy around running at least the Release Candidates just to make sure everything is stable before the final lands. Beyond that, there are few thousand people testing these publicly available pre-releases every time, reporting bugs as necessary, all before the final release lands.

Otherwise, leave the auto-updates on and never worry about updating your site again, let WordPress handle it. And, of course, follow along at https://make.www.ads-software.com/core/ and/or even get involved yourself. ??

Also, if you’re interested:

A near-final roundup of what’s to come in 4.4: https://make.www.ads-software.com/core/2015/11/11/wordpress-4-4-field-guide/

How the Release Cycle Works: https://make.www.ads-software.com/core/handbook/about/release-cycle/

And, the 4.4 release schedule: https://make.www.ads-software.com/core/version-4-4-project-schedule/

Thank you for your reply.

I wonder though if other WP-users feel the same way as I do about the release speed? Or are we just silent in this community?

To me WP is an empty building. The wires and plumbing are installed, but the furniture and life come from themes and plugins. Since it is a building I fail to see the point why my roof and windows needs to be replaced a way more often than is necessary.

I don’t see very many people upset about the update speed. When 4.3 was released, it was adopted at a faster rate than ever before, almost 400,000 updates in just 2 hours when I recorded my count. I’m having trouble tracking down the 24-hour exact total, but it was well over 1 million updates.

You’re certainly welcome to update at your own pace, just keep your eyes out for security releases, as I don’t recommend delaying those.

Slight correction above, WordPress 4.3 reached 1 million updates in less than 9 hours: https://twitter.com/obenland/status/633851511303331840

Thank you for your effort. Case closed.

If anyone else wants to share they thoughts, they are welcome to do so.

You’re welcome!

It’s also worth noting that ever since auto-updating was implemented for minor versions in 3.7, security fixes have been getting continuously backported to those releases with new minor versions, thus keeping those who choose to not update to the latest release still secure. This is one of the main reasons that 3.7 is up to 3.7.11 now.

That said, this is a courtesy, basically. We only recommend the latest release as the “current” release. Still, the track record on backporting security fixes to get into auto-updates is solid, so if you do decide to stick to an older version for a while, leave the auto-updater enabled to get those security-only fixes.

I wonder if other CMS providers have slower approach?

Well, one comparison would be Drupal. They just recently released Drupal 8, last week. For comparison, Drupal 7 was released in early January, 2011.

Their release cycle is certainly slower, but at the same time, every major release for them is a “breaking” release. There’s almost never a direct upgrade path. Instead they use migration modules and similar other code to basically import content from the old site to the new site.

WordPress, on the other hand, has backwards compatibility as one of the main goals of the project. You can take a site running WordPress 0.7, and upgrade it directly to WordPress 4.4, and it will work. That’s upgrading a site through about 28 major version releases, spanning 12 years, in a single step.

The upgrade process for WordPress is very robust. Plugins and themes, sometimes not so much. Generally themes have very few problems. With plugins, the simpler the plugin is, the better it works. It’s only large, complex, plugins that tend to have problems. But for the most part, WordPress upgrades try to preserve backwards compatibility to a rather insane level you won’t find in other projects.

It’s also worth noting that ever since auto-updating was implemented for minor versions in 3.7, security fixes have been getting continuously backported to those releases with new minor versions, thus keeping those who choose to not update to the latest release still secure.

I did not know that. That’s valuable information, thank you.