This schedule assumes several things:
- Contributors stick to time commitments and project cycle schedules
- We absolutely do not let scope creep get the better of us
- 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. |
| September 26, 2012 | Hard freeze on feature development. Stop feature development; focus on testing and compatibility (supported platforms, browsers, RTL, accessibility, etc). Ship a 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, 2012 October 24, 2012 October 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, 2012 November 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). | November 30-Dec. 3 | Final Release Candidate, if necessary. |
| December 5, 2012 | Target date for WordPress 3.5 launch. |
To get involved in WordPress core development, head on over to Trac and pick a 3.5 ticket. Need help? Check out the Core Contributor Handbook.
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!
niklasbr 1:02 pm on August 13, 2012 Permalink | Log in to Reply
Even though I have scoured the net I don’t know where to best ask this question, please direct me elsewhere if this is the wrong place.
With your current versioning scheme you add
• functionality
• change UI
• Change API (including new and/or deprecate it)
with point releases.
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”.
Andrew Nacin 5:10 pm on August 31, 2012 Permalink | Log in to Reply
We use the first two pieces to identify a version number. 2.9, 3.0, 3.1 are all equivalent “major” releases. 3.3.1 is a “minor” release. We do not have micro releases.
You can think of “3.3″ as instead “33″ (although it is really like 18, or something) “4.0″ as “40″, etc.
I will write up a page on http://make.wordpress.org/core/handbook/ to more thoroughly explain our version numbering. I agree it is confusing; it’s just how we’ve always done it.
The statements in your final paragraph are accurate.
Alex Mills (Viper007Bond) 9:43 pm on August 31, 2012 Permalink | Log in to Reply
We should just drop the first period and get it over with.
Mike Bijon 6:00 pm on September 5, 2012 Permalink | Log in to Reply
+1
Andrew Nacin 10:28 pm on August 16, 2012 Permalink | Log in to Reply
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.