Version 3.4 Project Schedule

Per recent development chats, we are working out a project schedule for 3.4. This schedule assumes several things:

  • Assigned teams live up to time commitments and project cycle schedules
  • We absolutely do not let scope creepscope creep The tendency for requirements to increase during a release's development cycle beyond those originally approved for the upcoming release. Something to be avoided. Also known as feature creep. get the better of us
  • All committers slog through has-patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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.4
  • No one gets really sick, has a baby, gets married, etc.
  • 3 weeks of betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process., 2 weeks of RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).
  • No missing deadlines

The plan:

January 11, 2012 Confirm proposed scope, assign teams.
January 18, 2012 Pre-cycle feature/scope explorations and early dev. Miscellaneous fixes and early patches.
January 25, 2012 Confirm first round 2-week cycle plans with assigned teams. Begin new process (blogblog (versus network, site) posts, etc). [Insert list of this week’s team assignments]
February 1, 2012 2-week cycles continue. Assign teams for subsequent feature cycles. [Insert list of this week’s team assignments]
February 8, 2012 2-week cycles continue. Assign teams for subsequent feature cycles. Begin integration of usability testing with cycles as features are added. [Insert list of this week’s team assignments]
February 15, 2012 2-week cycles continue. Assign teams for subsequent feature cycles. Continue integration of usability testing with cycles as features are added. [Insert list of this week’s team assignments]
February 22, 2012 2-week cycles continue. Assign teams for subsequent feature cycles. Continue integration of usability testing with cycles as features are added. [Insert list of this week’s team assignments]
February 29 March 2012 Freeze! Everyone review everything else. Formal QA review. Since there will have been testing in the mini-cycles, we shouldn’t need a standalone usability testing or unit testing period, but we do need to stop and test everything working together on all the supported platforms (including accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)-specific).
From this point on, no more commits for any new enhancements or feature requests in this release cycle (including blessed), only bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 ticketticket Created for both bug reports and feature development on the bug tracker. and have it ready for 3.5 early.
March 7 March 2012 Fixes based on QA report. Since there will have been testing in the mini-cycles, we shouldn’t need a standalone usability testing or unit testing period, but we do need to stop and test everything working together on all the supported platforms. Note: This week coincides with SXSW interactive. Maybe we can get a hacker group together once or twice to plow through bug tickets.
March 14 April 4, 2012 Target date for beta 1.
UIUI User interface 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 and subsequent RC.
March 21 April 11, 2012 Target date for beta 2.
March 28 April 18, 2012 Target date for beta 3.
April 4 April 25, 2012 Target date for RC 1. String freeze; translators rejoice.
April 11Â May 2, 2012 Target date for RC 2.
April 18 May 9, 2012 Target date for WordPress 3.4 launch.

So: if you have made a 2012 new year’s resolution to get involved in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development, now’s the time to head on over to TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and pick a 3.4 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!