Freeze (just in time for fall!)

It’s that time in the dev cycle again: feature freeze. As usual, we are running a bit behind. We were supposed to have freeze a week ago for everything being worked on by contributors, then a week for the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team to do a scrub and commit or puntpunt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.) all those enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature./feature requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. tickets as well as finishing up their own 3.3 feature dev before full on freeze today. We gave contributors some extra time at last week’s dev chat as there were some features not quite ready (HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. emails, Settings CSSCSS Cascading Style Sheets., etc). Sadly, the extra time didn’t lead to commits, and now we’re just a week behind. So!

This is freeze.

1. All enhancements and feature requests that do not have a ready 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. will be punted.
2. All enhancements and feature requests that have a patch but no comments showing that the patch has been adequately tested will be punted.
3. All enhancements and feature requests that have a patch that has been adequately tested will be reviewed by the core team and either committed or punted.
4. No more enhancements or feature requests will be added to the 3.3 milestone.
5. The core team will commit their remaining new features, and Jane + some UXUX User experience volunteers will do some testing of UIUI User interface changes over the coming week. Core team (and anyone who volunteers to help) will revise UI of new features based on findings during testing on a rolling basis.

Then comes 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., during which we’ll be in 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.-fix-only mode. Yes, there is such a thing as a UI “bug,” but “we should have done this sooner” is not a bug.

This cycle has already seen two deadline pushes, so from now on we’re going to do our best to be mercilessly strict with the deadlines, even if it means cutting things. Anything that isn’t ready will be cut. “not done” is not the same as “has bugs,” and we need to be better about respecting that difference. We had plenty of time to get these things in; we all made decisions about priorities over the last few months.

It is now too late to ask us to get something in for 3.3. Start working on it for early 3.4.

#3-3, #schedule