{"id":122596,"date":"2026-04-02T18:53:14","date_gmt":"2026-04-02T18:53:14","guid":{"rendered":"https:\/\/make.wordpress.org\/core\/?p=122596"},"modified":"2026-04-02T19:28:01","modified_gmt":"2026-04-02T19:28:01","slug":"the-path-forward-for-wordpress-7-0","status":"publish","type":"post","link":"https:\/\/make.wordpress.org\/core\/2026\/04\/02\/the-path-forward-for-wordpress-7-0\/","title":{"rendered":"The Path Forward for WordPress 7.0"},"content":{"rendered":"

It was announced earlier this week<\/a> that the final 7.0 release has been delayed specifically to allow more time to address testing feedback about the implementation of real-time collaboration. While the broad reasons for the delay were shared, this post will clarify what the delay means in practice (\u201creturning to betaBeta<\/span> 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.<\/span><\/span><\/span>\u201d after entering the Release Candidaterelease candidate<\/span> 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)<\/a>.<\/span><\/span><\/span> phase of a release is unprecedented), and how to handle some specific technical details. Having clear guidance helps to direct attention to the right areas and ensures that the delay is as minimal as necessary.<\/p>\n\n\n\n

This post outlines the policies dictating what can move forward, and the processes that should be followed until further notice to best focus community efforts while promoting stability and the ability to remain nimble.<\/p>\n\n\n\n

Committing<\/h2>\n\n\n\n

To help CoreCore<\/span> Core is the set of software required to run WordPress. The Core Development Team builds WordPress.<\/span><\/span><\/span> committers understand what types of commits are allowed during this pause, the following policies are now (or continue to be) in place:<\/p>\n\n\n\n

For non-Committercommitter<\/span> 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.<\/span><\/span><\/span> contributors, this section may help explain why Core committers make certain decisions.<\/em><\/p>\n\n\n\n

Commits to trunk<\/code><\/h3>\n\n\n\n

To avoid the potential for merge conflicts while backporting and other complexities, trunktrunk<\/span> 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.<\/span><\/span><\/span><\/strong> is closed to commits for the 7.1 release until further notice<\/strong>.<\/p>\n\n\n\n

Backporting to the 7.0 Branchbranch<\/span> 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\".<\/span><\/span><\/span><\/h3>\n\n\n\n

Changes Allowed<\/h3>\n\n\n\n

The typical rules followed during the Release Candidate phase of the release cycle will remain in effect:<\/p>\n\n\n\n

Backporting commits<\/strong><\/a> will continue to require double sign-off by two core committers.<\/strong> The commit dev-feedback<\/code> keywords should be used to request a second committer\u2019s review, and dev-reviewed<\/code> should be added to indicate a second committer has reviewed and approved performing the merge to the 7.0<\/code> branch.<\/p>\n\n\n\n