Version 3.5 Project Schedule

All committers slog through has-patch tickets regularly so patches don’t sit unattended until the end of cycle

Freeze means freeze

No major security issues crop up and pull people away from 3.5

No one gets really sick, has a baby, gets married, etc.

Up to 6 weeks of beta and 4 weeks of RC

No missing deadlines

The plan:

July 11-18, 2012

Confirm proposed scope.

July 25, 2012

Until now, focus has been on miscellaneous fixes and early patches, and exploring individual feature proposals (comps, brainstorming, etc.). We should be ramping up the development cycle here.

August 5, 2012

WordCamp San Francisco Hack Day. Initial gut check for feature planning and early development. Work through early-stage problems.

September 5, 2012

Soft freeze on feature development. This is an evaluation period. Here, we mercilessly cut things and quickly reassign contributors to things that need more attention. Three weeks until the hard freeze and beta 1.

From this point on, no more commits for any new enhancements or feature requests in this release cycle, only bug fixes. Any enhancements/feature requests not completed and committed by this point will be punted to future. Please don’t get angry and complain when this happens; it’s necessary to get us to an on-time release. You can keep working on your pet ticket and have it ready for 3.6 early.

October 10, 2012

Beta 2 target date. Two weeks after beta 1.

October 17, 2012October 24, 2012October 31, 2012

Betas 3, 4, 5. Keep the pressure up with an option for a beta release every Wednesday. (No more than two weeks between betas.)

November 7, 2012

Release Candidate 1 target date. Two weeks after beta 3. String freeze. Any work is focused on regressions and blockers only.

November 14, 2012November 21, 2012

Release Candidates 2, 3, as needed. No more than two weeks between RCs. Must have at least a second RC on or before November 21, to keep us on track for December 5 (Thanksgiving is November 22).

Get your patches done and submitted as soon as possible, then drum up people to test the patches and leave feedback on the ticket. As stated above, no patches for enhancements or feature requests will be committed after the posted deadlines, so that we can all focus on squashing bugs and hopefully deliver the most bug-free WordPress to date. Wish us luck!

What makes this different from major 3.0/4.0/5.0 releases? This is not necessarily a bad thing, it is perhaps only I who find this confusing and annoying. As an example the 3.4 branch contains security fixes that are not in the 3.3 branch, and if everything would be perfect every plugin and theme author would provide changes immediately or within days from the release, but it doesn’t actually happen.

For example, a customer of mine is still waiting for the last plugins to be ported to 3.4 (they are slowly coming there). Meanwhile they are open for attacks against published security holes. Would it be possible to do Feature/API changes separate from maintenance releases containing bug and security fixes? I am afraid if nothing happens the story will go on:

1. New awesome version of WordPress gets released, it contains hundreds of improvements to UI/API and bug fixes/security fixes.
2. Wait a while (sometimes weeks or more) for every plugin maker to complete testing.
3. Test that all updated plugins works well in unison.
4. Go live.
5. New awesomer version of WordPress gets released… Rinse, repeat.

Making clearer how version numbers are supposed to work and separating the UI/API changes would not be the perfect solution, but it would go a good long way to mitigating problems caused by the bundling of everything.

If I also could identify API changes by version numbers, say 3.X > 3.Y always contains API changes I could perhaps write a plugin that hooks into the update process that tells my customers “wait a minute, this update contains stuff that could potentially break stuff” or if the version is 3.3.X > 3.3.Y “this update only contains bug and security fixes, it is unlikely (but not impossible) that something might break”.

This originally had September 3 and September 25 as the feature development deadlines. These were designed to land on Wednesdays, like most of our deadlines (the day of our weekly IRC meeting), so they’ve been edited. Who knows what I was looking at originally.

Welcome to Make WordPress Core!

This is the official blog for the core development team of the WordPress open source project. Follow our progress with weekly meeting agendas, project schedules, and the occasional code debate.