This schedule assumes several things:
- Contributors stick to time commitments and project cycle schedules
- We absolutely do not let scope 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-patch 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.5
- No one gets really sick, has a baby, gets married, etc.
- Up to 6 weeks of beta 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. and 4 weeks of RC 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
|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 WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. 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 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), 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 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 ticket Created for both bug reports and feature development on the bug tracker. 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 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). 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development, head on over to Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. 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!