WordPress 7.0 Release Candidate Phase  🔗 **Source:** [WordPress 7.0 Release Candidate Phase](https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/) > [!note]+ Document Notes > tags: #wordpress #core-development #release-management #version-control > author: Jeffrey Paul > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/ > date created: 2024-12-19 15:30 > > # 🏷️ Title: WordPress 7.0 Release Candidate Phase > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Monitor double sign-off requirement for trunk commits — until 7.0 branch created #core-development - [H2] Track string freeze implications for Polyglots team — translation delayed until branching #internationalization - [H3] Review regression tickets and test suite expansion — only allowed on 7.0 milestone #quality-assurance ## 🧭 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]] ### 🔗 References - [WordPress 7.0 Release Candidate Phase](https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/) - [WordPress Project Roadmap](https://make.wordpress.org/core/) ## 📝 Summary - WordPress 7.0 has entered Release Candidate phase with specific commit policies - Technical issue prevents 7.0 branch creation until RC2, requiring double sign-off for trunk commits - Hard string freeze is in effect, blocking new translatable strings - Only regression fixes and test suite expansions allowed on 7.0 milestone - Trunk will bump to 7.1-alpha after 7.0 branch creation ## 📖 Main Content WordPress 7.0's Release Candidate phase introduces strict governance policies for core development. A technical issue referenced in ticket #64393 has delayed branch creation until RC2, creating an unusual situation where all trunk commits require approval from two core committers instead of the typical single-committer workflow. The string freeze policy prevents addition of new translatable text, though the Polyglots team cannot begin translations until the 7.0 branch exists. This creates a temporary bottleneck in the internationalization process. Critical strings like About page content can receive exceptions with proper Trac tagging and team notification. The milestone management restricts ticket placement to two categories: regressions introduced during the 7.0 cycle and test suite expansions. This maintains release quality while allowing continuous testing improvements regardless of code freezes. ## 🗒️ Notes #### 📋 Release Candidate Policies Overview - Key idea: WordPress 7.0 RC phase implements strict committing and milestone policies - Evidence: "Now that WordPress 7.0 has entered the Release Candidate phase, the following policies are in place" #### ⚠️ Technical Issue Delays Branching - Key idea: Branch creation postponed to RC2 due to unresolved technical problem - Evidence: "Due to a technical issue that must be resolved before the 7.0 branch is created, branching has been delayed until RC2" #### 👥 Double Sign-off Requirement - Key idea: All trunk commits need two core committer approvals until branching - Evidence: "All commits to trunk will require double sign-off by two core committers until the 7.0 branch is created" #### 🔍 Dev-feedback Review Process - Key idea: Specific Trac keywords manage the two-committer review workflow - Evidence: "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" #### ✅ Test Suite Exception - Key idea: Test commits bypass double sign-off requirements - Evidence: "Commits to the test suite do not require double sign-off" #### 🌐 String Freeze Implementation - Key idea: RC1 triggers hard string freeze preventing new translatable text - Evidence: "RC1 release marks the hard string freeze point of the release cycle" #### ⏸️ Translation Delay Impact - Key idea: Polyglots team cannot begin translations without version branch - Evidence: "Strings will not be available for translation until the 7.0 branch is created" #### 🚫 New String Prohibition - Key idea: No new translatable strings allowed except critical exceptions - Evidence: "No new strings are permitted. Exceptions can be made for critical strings (the About page, for example)" #### 🏷️ Critical String Exception Process - Key idea: Critical strings need Trac tagging and Polyglots team notification - Evidence: "Provided they are properly tagged with the i18n-change keyword in Trac and the Polyglot team is made aware" #### 🐛 Regression-only Milestone Policy - Key idea: Only regression fixes and test expansions allowed on 7.0 milestone - Evidence: "Only two types of tickets may be placed on/remain on the 7.0 milestone: Regressions...Test suite expansion" #### 📈 Test Suite Flexibility - Key idea: Testing improvements can proceed regardless of code/string freezes - Evidence: "Tests can be committed at any time without regard to code or string freezes" #### 🔄 Version Bump Planning - Key idea: Trunk advances to 7.1-alpha after 7.0 branch creation - Evidence: "After the 7.0 branch is created following RC2, a follow-up post will be published announcing that trunk is open for commits related to the next version" ## 📚 References - [WordPress Core Development Handbook](https://make.wordpress.org/core/handbook/) - [Trac Ticket #64393](https://core.trac.wordpress.org/ticket/64393) - [Polyglots Team Documentation](https://make.wordpress.org/polyglots/teams/) ## 🗣️ Paraphrase - WordPress 7.0's release candidate phase requires two core developers to approve any code changes to the main development branch due to a technical problem preventing the creation of a separate 7.0 branch until the second release candidate - The usual translation process is on hold because translators need a dedicated version branch to work with, though the normal rules about not adding new text strings are still in effect with limited exceptions for critical content - Only bug fixes for problems introduced during 7.0 development and testing improvements can be added to the 7.0 release at this point, with the main development branch moving to version 7.1 work once the 7.0 branch is finally created ## 📰 Newsletter WordPress 7.0 has entered its Release Candidate phase with some unique challenges! Due to a technical issue, the team is implementing double sign-off requirements for all trunk commits until RC2 when the 7.0 branch can be created. **What this means for you:** - String freeze is active, so translations are temporarily on hold - Only regression fixes and test improvements are being accepted - Extra review processes ensure release quality This careful approach demonstrates WordPress's commitment to stability while managing unexpected technical hurdles. The community's collaborative review process helps maintain the high standards we expect from major releases. Resources: [Core Handbook](https://make.wordpress.org/core/handbook/), [Developer Docs](https://developer.wordpress.org/), [Make WordPress Core](https://make.wordpress.org/core/) ## ✅ Action Items #### WordPress - Core: Monitor #64393 resolution for branch creation timeline - Core: Implement dev-feedback/dev-reviewed keyword workflow in Trac - Core: Coordinate with Polyglots on string freeze exception requests - Polyglots: Prepare translation workflows for delayed branch availability - Documentation: Update contributor guides with RC phase requirements - Community: Communicate milestone restrictions to plugin/theme developers #### OSPO - Policy & Governance: Document double sign-off precedent for future releases - Security Management: Review RC phase vulnerability disclosure procedures - Community Engagement: Support core committer coordination during restricted phase ## 🧪 Hypotheses - Double sign-off requirements will reduce commit velocity but improve code quality during critical release phases - Delayed branching creates translation bottlenecks that could impact international WordPress adoption timelines - Restricting milestone scope to regressions and tests will improve focus on release-critical issues - The technical issue causing branch delay may indicate underlying version control or automation problems ### 📊 Methodology - Track commit frequency and approval times before/during/after double sign-off period - Measure translation completion rates compared to previous releases with standard branching - Analyze ticket closure rates and quality metrics during restricted milestone period ### ❓ Questions - What specific technical issue prevents branch creation and how can similar problems be prevented? - How do other major open source projects handle release candidate governance and branch management? - What metrics should guide decisions about implementing double sign-off in future releases? ### 🔮 Future Research - Analyze correlation between release governance strictness and post-release bug reports - Study impact of translation delays on WordPress adoption in non-English markets - Investigate automated tooling to reduce manual coordination burden during RC phases ### 💡 Implications - Practice: Contributors must adapt workflows to accommodate extended review cycles and milestone restrictions - Policy: Establishes precedent for enhanced governance during technically challenging releases - Security: Dual approval reduces risk of problematic code entering release candidates - Education: Community needs updated guidance on RC phase expectations and processes ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical project management content) #### 👀 Visual learners - Present: Clear section headings and policy structure - Improve: Workflow diagrams showing commit approval process, timeline visualization #### 🔊 Aural learners - Present: Referenced weekly core meetings and Slack discussions - Improve: Audio summary of key policy changes, recorded policy explanation #### 🗣️ Verbal learners - Present: Technical term definitions (trunk, branch, committer) - Improve: Analogies comparing RC phase to other software release processes #### 🧩 Kinesthetic learners - Present: Specific keyword usage examples (dev-feedback, dev-reviewed) - Improve: Step-by-step commit process checklist, hands-on Trac workflow guide #### 🧠 Logical learners - Present: Clear policy logic and exception criteria - Improve: Decision tree for commit approval process, policy rationale explanations #### 🧑‍🤝‍🧑 Social learners - Present: Team collaboration emphasis, peer review processes - Improve: Discussion prompts for core meetings, collaboration best practices #### 🧘‍♀️ Solitary learners - Present: Self-contained policy reference - Improve: Individual contributor checklist, personal workflow adaptation guide #### 🌿 Naturalistic learners - Present: Organic community development process - Improve: Ecosystem impact explanations, community health connections ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Proper heading hierarchy, clear section structure - Improve: More descriptive link text, ARIA labels for policy sections #### Keyboard navigation - Present: Standard WordPress.org navigation structure - Improve: Skip links to policy sections, keyboard shortcuts documentation #### Contrast and readability - Present: Standard WordPress.org theme contrast - Improve: Verify technical term readability, check code snippet contrast #### Text resizing and reflow - Present: Responsive design supports zoom - Improve: Test policy tables at high magnification levels #### Media and captions - Present: Text-based content, no multimedia - Improve: Consider audio policy summaries with transcripts #### Forms and interactions - Present: Basic comment form accessibility - Improve: Accessible feedback mechanisms for policy questions ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global contributor acknowledgment, international team impact - Improve: Timezone considerations for review processes, regional impact analysis #### Inclusive language - Present: Professional, technical vocabulary with definitions - Improve: Plain language policy summaries, avoid development jargon #### Neurodiversity support - Present: Clear structure with consistent formatting - Improve: Summary boxes for key policies, visual policy indicators #### Representation - Present: Diverse contributor acknowledgments - Improve: Highlight international community impact, accessibility perspectives #### Psychological safety - Present: Collaborative tone, peer review emphasis - Improve: Clear escalation paths for policy questions, supportive language ### ✅ Logical Validity #### Strong reasoning - Deductive strength: RC phase policies logically follow from release quality goals - Inductive strength: Double sign-off based on successful precedent in critical situations - Causal reasoning: Technical issue directly causes need for enhanced review processes - Analogical strength: String freeze policies consistent with previous major releases #### Fallacies - None identified: Policy explanations are straightforward and well-reasoned #### Tone of voice - Overall tone: Professional, authoritative, collaborative - appropriate for technical governance communication ### 🛡️ DARVO Analysis - Deny: No denial patterns present in straightforward policy communication - Attack: No attacking language toward any groups or individuals - Reverse victim/offender: No victim/offender dynamics in technical policy content - Emotional cues and rhetoric: Neutral, factual tone appropriate for governance documentation ## 🎯 Conclusion WordPress 7.0's Release Candidate phase demonstrates adaptive governance in response to technical challenges. The double sign-off requirement and delayed branching create temporary constraints that prioritize release quality over development velocity. Contributors should prepare for extended review cycles and focus contributions on regression fixes and testing improvements until the 7.0 branch creation enables normal development workflows. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] RC phases require enhanced governance for quality > [!quote] [WordPress 7.0 Release Candidate Phase](https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/) by [[Jeffrey Paul]] via [[Make WordPress Core]]. Published 2026-03-25. Accessed 2024-12-19. > "Now that WordPress 7.0 has entered the Release Candidate phase, the following policies are in place." Establishes formal policy framework for critical development phases. [view highlight](https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/#H1) #xref #articleseed ID:rw_governance_rc_policies ### [H2] Technical issues can force enhanced review requirements > [!quote] [WordPress 7.0 Release Candidate Phase](https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/) > "All commits to trunk will require double sign-off by two core committers until the 7.0 branch is created." Demonstrates adaptive governance responding to technical constraints. [view highlight](https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/#H2) #xref ID:rw_technical_constraints_governance ### [H3] String freezes coordinate with translation workflows > [!quote] [WordPress 7.0 Release Candidate Phase](https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/) > "Strings will not be available for translation until the 7.0 branch is created." Shows interdependence between technical processes and localization. [view highlight](https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/#H3) #xref ID:rw_string_freeze_coordination --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] RC governance adapts to technical constraints - Applied when technical issues prevent normal branching workflows - Referenced throughout policy explanation - Links: [[Release-Management]] [[Technical-Governance]] #### [Z2] Double sign-off balances quality with velocity - Used during critical release phases requiring enhanced review - Demonstrated in trunk commit requirements - Links: [[Code-Review]] [[Quality-Assurance]] #### [Z3] Milestone restrictions focus release efforts - Implemented by limiting ticket scope to regressions and tests - Applied during RC phase ticket management - Links: [[Project-Management]] [[Release-Planning]] --- ### ✏️ Fleeting Queue - [F1] Research other projects' RC phase policies — comparative analysis needed #fleeting #inbox - [F2] Document double sign-off impact on contributor experience — workflow friction study #fleeting #inbox - [F3] Track translation delay effects on international releases — localization impact metrics <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/WordPress 7.0 Release Candidate Phase|WordPress 7.0 Release Candidate Phase, make.wordpress.org]] ## Highlights - 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.0` branch is created.** ([View Highlight](https://read.readwise.io/read/01kmjqrts40qx8822c4kc906t8)) - Tags: 👻 ai highlighted