Today at WordCamp San Francisco, Matt Mullenweg presented the plan for the upcoming 3.7 and 3.8 releases of WordPress. In a nutshell, they will be small, developed in parallel, and (assuming all goes to plan) both released by the end of 2013.
This is hugely exciting!
The plan for these two releases makes sense and will help keep our code both robust and rapidly developed. It also paves the way for what I think would be the ideal plan for WordPress 3.9 and 4.0.
An Existing Model
When jQuery planned for a recent release, they forked their own project. Instead of releasing just one product, the team simultaneously released two versions: 1.9 and 2.0.
Both branches[ref]Since both versions of jQuery are maintained by the same team, it’s not a true fork.[/ref] of the project implement the same API, but the 2.X branch contains several speed improvements: namely, dropping compatibility support with older browsers and removing deprecated functionality:
You asked for it, you got it: jQuery 2.0 has arrived!
As promised, this version leaves behind the older Internet Explorer 6, 7, and 8 browsers. In return it is smaller, faster, and can be used in JavaScript environments where the code needed for old-IE compatibility often causes problems of its own.
Developers now have a clear choice when building their projects – maintain support for older browsers if necessary, or upgrade project requirements and leverage a faster framework.
WordPress
There has been a lot of talk about forking WordPress in recent months. I’m suggesting a similar, albeit slightly different approach.
WordPress doesn’t need any more schisms in the community. Forking the project to create a separate, discrete application would be a huge disservice to developers, clients, customers, and every variation of stakeholder in between.
Instead, I think we should follow jQuery’s example and release two, separate, complimentary branches of WordPress at the same time.
Background
At the WordPress Community Summit last October, Matt presented a fairly damning slide detailing WordPress’ system performance over the history of our various releases. Despite every claim that new releases of WordPress are faster than their predecessors, only one release actually lived up to that claim.
Every subsequent release is faster not necessarily due to optimized code, but due to the fact that the underlying hardware continues to advance.
WordPress today is a robust application framework. But to use that application framework, we have to drag along the collective bloat of 50+ releases worth of backwards compatibility, huge swaths of deprecated (or poorly designed) functionality, and workarounds for features lacking in older versions of PHP.
Dropping much of this cruft – while still maintaining the current API – would be a huge gain.
The Road Ahead
After WordPress 3.8 is out, I propose we work in two groups:
- The collection of teams is responsible for building the 3.9 API
- A team to walk through the code base and upgrade where possible
When we release 3.9 and 4.0, the APIs should be identical. Any code written to run on WordPress 3.9 (with no deprecated notices, of course) will also run on 4.0. The differences between the versions would include;
- Upgrading the minimum PHP version requirement (allowing the use of namespaces, closures, and possibly traits)
- Removing all functionality deprecated before version 3.9
- Refactoring bottlenecks in code (i.e. $wpdb) for performance
The Future
When WordPress 3.9 and 4.0 are released, we will keep minor releases in sync (possible through 3.10 and 4.1 and beyond). This will allow developers to build code utilizing newer PHP features by making the 4.0 release of WordPress a requirement. It will also allow end-users to keep using WordPress on an un-upgraded server.
However, the dual release will also put pressure on developers, clients, and hosts to begin upgrading their infrastructure to support newer requirements – but without making the upgrade a hard requirement.
Why?
I write code for a living. Most of my projects are deployed on servers that play well with newer APIs or boxes which I can control myself. As a result, I can already use advanced PHP features in my projects (and leverage certain performance benefits at the same time).
I also give code away for fun – but that code has to function back to the minimum system requirements for WordPress. I want to present a clear path for upgrading these requirements, one that’s beneficial to both developers and our customers.
I think a 3.9/4.0 dual release is the way to do that – and I’m more than happy to help make this a reality. What do you think?