Now that WordPress 6.6 has entered the 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). (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).) phase, the following policies are in place.
These policies mainly cover how and when Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers can commit. For non-committing contributors, this post may help explain why a Core committer A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. makes a certain decision.
String Freeze
To allow the Polyglots team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. time to get their local language’s translation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. of WordPress ready, no new strings are permitted to be added to the release. Existing strings can be removed and/or duplicated if needed.
Seek guidance from the Polyglots team leadership for any strings reported as buggy. A buggy string is one that can not be translated to all languages in its current form. In such case, another RC may eventually be released to update the related strings. This will be done in a responsible and reasonable manner, only when necessary.
Tickets on the WordPress 6.6 milestone
For the remainder of the cycle, only two types of tickets may be placed on/remain on the 6.6 milestone:
- Regressions: bugs that have been introduced during the WordPress 6.6 development cycle, either to existing or new features.
- Test suite expansion: tests can be committed at any time without regard to code or string freezes. This can cover either new or existing features.
Trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. is now WordPress 6.7-alpha
WordPress 6.6 was recently forked to its own branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"., trunk is now open for commits for the next version of the software.
Backporting to the 6.6 branch
Backporting commits of production code (that is, anything that ends up in the zip file) now requires double sign-off by two core committers. The dev-feedback keyword should be used to request a second committer’s review, dev-reviewed should be added to indicate a second committer has reviewed and approved the commit to the 6.6 branch.
Commits to the test suite and docblock (phpdoc, xref, inline docs) changes do not require double sign-off.
Props to @peterwilsoncc for writing the initial post that inspired this one, and to @meher and @hellofromtonya for peer review.
#6-6
