Per recent development chats, we’ve worked out a project schedule for 3.3. The plan:
|July 20, 2011||Confirm planned timeline.|
|July 27, 2011||Confirm planned¬ scope.|
|Non-Leads Feature freeze. No new features added after this point by contributors. After this a week for lead developers to assess the state of trunk and identify anything that needs to be pulled for lack of maturity, or to drop in things that were intended for the release but hadn’t been finished yet.|
||Complete Feature freeze. No new features added after this point, so that testing can begin on a stable-ish product (including usability testing of new features).|
||Usability Test Results. Review results of testing, make fixes based on findings.|
|Target date for beta 1.
UI freeze and primary code freeze. Any last adjustments based on testing after feature freeze should be finished by now and the focus shifts to fixing bugs to get to a stable beta.
|From this point on, no more commits for any new enhancements or feature requests in this release cycle¬ (including blessed), 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.4 early.|
|Target date for RC 1. String freeze; translators rejoice.|
||Target date for WordPress 3.3 launch.|
So: if you have made a 2011 new year’s resolution to get involved in WordPress core development, now’s the time to head on over to Trac and pick a 3.3 ticket (that sounds kind of like a carnival game, doesn’t it?). 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!