WordPress 7.1 Release Candidate Phase  🔗 **Source:** [WordPress 7.1 Release Candidate Phase](https://make.wordpress.org/core/2026/08/05/wordpress-7-1-release-candidate-phase/) > [!note]+ Document Notes > --- > tags: [wordpress-7-1, release-candidate, core-commits, string-freeze] > author: Aaron Jorbin > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/08/05/wordpress-7-1-release-candidate-phase/ > date created: 2026-08-06 15:31 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: WordPress 7.1 Release Candidate Phase > ## 🧭 Table of Contents > - Summary > - Main Content > - Notes > - References > - Paraphrase > - Newsletter > - Action Items > - Hypotheses > - Methodology > - Questions > - Future Research > - Implications > - Learning Styles Assessment > - Accessibility Assessment > - DEIB Assessment > - Logical Validity > - DARVO Analysis > - Conclusion > - Refactor Appendix > ### 🔗 References > - https://make.wordpress.org/core/2026/08/05/wordpress-7-1-release-candidate-phase/ > - https://wordpress.org/news/2026/08/wordpress-7-1-release-candidate-1/ > - https://core.trac.wordpress.org/tickets/major > ## 📝 Summary > - What happened: WordPress 7.1 entered Release Candidate phase, so Core commit policy tightened. > - Why it matters: the post converts release timing into practical rules for committers, translators, testers, and non-committing contributors watching Trac activity. > - Stakeholders: Core committers, Core Program Team, Polyglots, test contributors, release leads, plugin and theme developers tracking strings and regressions. > - Risks and tradeoffs: delayed branching protects GitHub Actions work but temporarily holds translation availability and keeps trunk under double sign-off. > - Bottom line: RC policy is a release-risk control, not a general development slowdown. > ## 📖 Main Content > The post announces policy boundaries after RC1. The most important control is double sign-off for trunk commits until the 7.1 branch exists. Test-suite commits are exempt, which keeps release confidence work moving while feature or behavior changes face extra review. > String freeze is also active. Because translation files depend on the version branch, the usual Polyglots handoff cannot fully start until that branch exists. The post keeps the normal hard-freeze rules in place: no new strings except critical tagged cases, and existing strings may be removed or duplicated when needed. > The milestone policy narrows 7.1 tickets to regressions and test-suite expansion. That helps contributors distinguish release-blocking work from future-cycle work. > ## 🗒️ Notes > - RC phase creates a temporary governance state: trunk remains active, but double sign-off reduces accidental release churn. > - Branch delay is tied to GitHub Actions work, so release process and infrastructure work are connected. > - Translation readiness depends on branch timing, not only string policy. > - The milestone policy gives triagers a simple yes/no rule: regressions and tests stay; other work moves out. > ## 📚 References > - Make WordPress Core post: https://make.wordpress.org/core/2026/08/05/wordpress-7-1-release-candidate-phase/ > - WordPress 7.1 RC1 announcement: https://wordpress.org/news/2026/08/wordpress-7-1-release-candidate-1/ > - Trac 7.1 milestone: https://core.trac.wordpress.org/tickets/major > ## 🗣️ Paraphrase > - WordPress 7.1 is in RC, so commit rules now prioritize stability. > - Until branching happens, two Core committers must approve trunk commits, except test-suite changes. > - String freeze has started, but translators need the branch before the release strings are available. > - The 7.1 milestone should only contain regressions and test expansion. > - After the branch exists, trunk can move toward 7.2-alpha. > ## 📰 Newsletter > WordPress 7.1 is now in its careful hands phase. Trunk commits need two Core committer approvals until the 7.1 branch appears, hard string freeze is active, and the 7.1 milestone is now for regressions and tests. If you’re triaging, this is a useful one-page map for what belongs in the release lane and what should wait for the next cycle. > ## ✅ Action Items > #### DevRel > - Explain the RC policy in contributor office hours and release-readiness posts. > - Build examples that show how `dev-feedback`, `dev-reviewed`, `i18n-change`, and regression labels should be used. > - Track questions from non-committers who need to understand why issues move off the milestone. > #### OSPO > - Treat the double sign-off rule as a release governance control worth documenting for sponsored contributors. > - Keep sponsor reporting tied to verified release tasks, not raw commit counts. > #### Community > - Share plain-language guidance for meetup organizers and contributor day leads. > - Route first-time contributors toward test expansion and regression reproduction. > #### WordPress > - Core: enforce double sign-off and keep milestone triage tight. > - Core Performance: test performance-sensitive regressions before RC changes land. > - Core AI: avoid late-cycle experimental changes unless they are regression fixes. > - Core Program Team: publish branch timing and update coordination notes when trunk opens for 7.2-alpha. > - Mobile: check whether app docs or copy depend on 7.1 strings. > - Playground: provide quick RC testing paths. > - Community: prepare contributor guidance. > - Training: update release-cycle lesson materials. > - Marketing: align messaging with RC stability. > - Support: prepare known-issue notes. > - Design: review only regression-relevant UI fixes. > - Documentation: flag docs tied to string or UI changes. > - Photos: no direct action beyond release comms awareness. > - TV: capture release-process walkthroughs. > - Polyglots: wait for the branch, then begin translation work. > - Accessibility: prioritize regressions and test coverage. > - Meta: support Trac and branch communication. > - CLI: smoke-test compatibility. > - Hosting: prepare RC testing guidance. > - Tide: no direct action beyond plugin ecosystem watch. > - Openverse: no direct action. > - Themes: test against RC. > - Plugins: test against RC and watch regression reports. > #### The WPOCC > - Use this as a governance example for release discipline and contributor clarity. > ### FAIR > - Track release policies as public governance artifacts that reduce dependency on private interpretation. > ## 🧪 Hypotheses > - Double sign-off lowers late-RC regression count. > - Test-suite exemption increases useful test commits during freeze. > - Branch delay reduces GitHub Actions disruption but delays Polyglots start time. > - Narrow milestone rules reduce triage ambiguity. > ### 📊 Methodology > - Compare regression counts before and after RC policy dates. > - Measure time from branch creation to first translation activity. > - Audit Trac milestone churn during RC. > ### ❓ Questions > - How long did branch delay last, and did it measurably protect GitHub Actions work? > - Which non-regression tickets were removed from the milestone? > - Were translators blocked in practice or only by policy? > ### 🔮 Future Research > - Compare 7.1 RC governance with prior major releases. > - Review whether double sign-off creates bottlenecks for low-risk fixes. > ### 💡 Implications > - Practice: contributors get clearer release boundaries. > - Policy: public rules reduce hidden decision-making. > - Security: regression focus helps protect release stability. > - Education: this post is a teaching artifact for release phases. > - Funding: sponsored contributors can align effort with release needs. > ### 🧠 Learning Styles Assessment > - Reading level estimate: grade 9-10 by structure and technical terms. > #### 👀 Visual learners > - Present: headings and bullets. > - Improve: add release timeline graphic. > #### 🔊 Aural learners > - Present: no audio. > - Improve: short release-office-hours explanation. > #### 🗣️ Verbal learners > - Present: clear policy prose. > - Improve: glossary for contributor roles. > #### ✋ Kinesthetic learners > - Present: actionable keywords. > - Improve: sample Trac workflow. > #### 🧮 Logical learners > - Present: conditional rules. > - Improve: decision table. > #### 👥 Social learners > - Present: references to committers and Polyglots. > - Improve: office-hours prompts. > #### 🧍 Solitary learners > - Present: standalone post. > - Improve: checklist download. > #### 🌿 Naturalistic learners > Now that WordPress 7.1 has [entered the Release Candidate phase](https://wordpress.org/news/2026/08/wordpress-7-1-release-candidate-1/), the following policies are in place. *These policies mainly cover how and when Core committers can commit. For non-committing contributors, this post may help explain why Core committers make certain decisions.* #### Committing to Trunk In order to not interfere with [ongoing efforts to improve github actions](https://make.wordpress.org/core/2026/07/30/leaner-steadier-phpunit-runs-for-upcoming-releases/), branching has been delayed until early next week. This post will be updated after the branch is created. **As a result, all commits to `trunk` will require double sign-off by two core committers until the `7.1` branch is created.** 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 trunk. Commits to the test suite do not require double sign-off. **Only committers should add the** `dev-feedback` **and** `dev-reviewed` **keywords.** #### String Freeze RC1 release marks the hard string freeze point of the release cycle. While this normally means the Polyglots team can begin translating strings from the upcoming release into their local language, a version-specific branch is required. **As a result, strings will not be available for translation until the `7.1` branch is created.** Despite this, the normal rules for hard string freeze will be followed: * No new strings are permitted. Exceptions can be made for critical strings (the About page, for example) provided they are properly tagged with the `i18n-change` keyword in Trac and the Polyglot team is made aware. * Existing strings can be removed and/or duplicated if needed. Seek guidance from the [Polyglots team reps](https://make.wordpress.org/updates/team-reps/) for any strings reported as buggy. A buggy string is one that can not be translated to all languages in its current form. #### Tickets on the WordPress 7.1 milestone Only two types of tickets may be placed on/remain on the [7.1 milestone](https://core.trac.wordpress.org/tickets/major): * **Regressions**: bugs that have been introduced during the WordPress 7.1 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. #### Bumping Trunk to WordPress 7.2-alpha After the `7.`1 branch is created, this post will be updated and a [@committers](https://profiles.wordpress.org/committers/) announcement will be made in slack informing everyone that `trunk` is open for commits related to the next version of the software., WordPress 7.1 Release Candidate Phase, Aaron Jorbin, 01kzc8xa9c5wkc0z7s5sagt5sw.