Héctor Prieto 2:11 pm on June 23, 2022
Tags: 6.1 ( 94 ) , planning ( 30 )

WordPress 6.1 Planning Roundup

WordPress 6.1 will be the third major release of 2022. Following WordPress 6.0 Arturo , 6.1 will aim to refine those experiences found in Arturo and in 5.9 Joséphine [ ref ]. In preparation, this post includes target dates, features, and a call for the release’s squad.

This release cadence will consist of a long alpha and two short beta Beta 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. periods before the release candidate 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) . phase. According to the schedule proposed below and the Gutenberg Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ release cadence, WordPress 6.1 would include up to Gutenberg 14.1 for a total of 11 Gutenberg releases, the same amount as WordPress 6.0 included.

Proposed WordPress 6.1 Schedule

Milestone	Date
Alpha ( trunk 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. open for 6.1 release)	May 3, 2022
Beta 1 & Feature Freeze	September 20, 2022
Beta 2	September 27, 2022
Release Candidate 1	October 4, 2022
Release Candidate 2	October 11, 2022
Release Candidate 3	October 18, 2022
Dry Run	October 24, 2022
WordPress 6.1 General release	October 25, 2022

Proposed WordPress 6.1 Release Leads

Release Lead Release Lead The community member ultimately responsible for the Release. : Matt Mullenweg
Release Coordinator: TBD
Core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Lead: TBD
Editor Tech Lead: TBD
Core Triage triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Lead: TBD
Editor Triage Lead: TBD
Documentation Lead: TBD
Marketing & Communications Lead: TBD
Test Lead: TBD
Design Lead: TBD

All release decisions will ultimately be this release teams’ to make and communicate while gathering input from the community.

Join The Squad!

If you are interested in being a part of 6.1’s release squad , please show your interest in the comments below. Roles can be shared among more than one person!

# 6-1 , # planning

David Baumwald 2:28 pm on June 23, 2022

I’d love to help( RC 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) . , Core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech, Triage triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. ).

I have one question. Is there a reason that there’s only two beta Beta 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. periods? The past couple of cycles(5.9 and 6.0) had three scheduled, with a fourth sometimes scheduled as “optional’.

I have concerns that we’re not allowing for enough time for strictly bug bug 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. fixing after a Beta has coalesced.
- Héctor Prieto 3:12 pm on June 23, 2022
  
  Hi David! Thanks for volunteering!
  
  Based on the experience of the 6.0 release cycle, feedback received indicates the Beta Beta 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. period was too long and the most stressful for the release squad. Also, the broader engagement and testing were lower in later Betas and went back up with RC1.
  
  This proposal tries to shorten that period by removing the last Beta week, but more optional Beta releases are still on the table if needed.
  - David Baumwald 3:27 pm on June 23, 2022
    
    Thanks. I understand that this is a proposed schedule, but I’d still prefer at least three betas. The “optional” betas are not planned for in terms of time.
    
    I believe that testing is indeed lower in beta Beta 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. than RC 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) . . However, I also think that testing is even lower in alpha.
    
    Based on difficulties in having to extend the cycle recently 5.9, I think keeping to at least that many betas is prudent.
    - jeffpaul 4:05 pm on June 23, 2022
      
      Amplifying David’s note above, I’ll note that I checked releases going back to 5.0 and none had less than 3 Beta Beta 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. releases. Given that the Beta period has been established as the sole period to focusing on resolving bugs, I’m a little concerned with the reduction of time to focus on those bugs.
      
      On the topic of testing feedback, we’ve historically seen the least feedback during Alpha and the most feedback post-release with a somewhat linear scale in between those two on amount of feedback received. If we’re concerned about trying to increase the testing feedback, I don’t believe shortening the Beta period will help here and more/better outreach and guidance would likely help.
      
      I had not seen any discussion on the Beta period being stressful (or at least moreso than Alpha or RC 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) . ), so I’d love to learn more about that to see how we can help ensure that’s reduced as feasible for 6.1 and future releases. Can you share details on that to see if there are alternate ways to reduce that stress (and potentially handle without a reduction in the length of the Beta timeframe)?
      - Héctor Prieto 5:04 pm on June 23, 2022
        
        Sure! This feedback came during the 6.0 retrospective (summary post to be released soon) as well as during informal chats with other folks.
        
        Some of the stress originates in the difficulty to decide whether some fixes qualify as bugs, especially when compared to the amount of feedback received during later Betas.
        
        Other retrospective feedback suggests moving the deadline for the Dev Notes to Beta Beta 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. 1 instead of writing them during the Beta period, which together with a long Beta phase will impact the availability for developers to wrap things before Beta 1. Reducing the Beta period could help ship Dev Notes before Beta 1.
        
        On the other hand, having duplicate roles in the release squad has greatly helped alleviate that burden.
        
        jeffpaul 5:18 pm on June 23, 2022
        
        Some of the stress originates in the difficulty to decide whether some fixes qualify as bugs, especially when compared to the amount of feedback received during later Betas.
        
        On this one it seems like perhaps a refreshed look at the text in Bug Gardening > 1. Ensure The Ticket Is A Bug may be helpful in more clearly providing guidelines on how to make this distinction between bugs/defects and features/enhancements?
        
        Other retrospective feedback suggests moving the deadline for the Dev Notes dev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.
        
        Right now Dev Notes and the Field Guide Field guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle . The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. are expected to be published by RC 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) . (or as is more historically accurate “around” / closely after RC). Are you suggesting that gets moved earlier in the cycle? It’s been rather difficult historically to get the Dev Notes and Field Guide published before RC so I’m curious how we could improve things to get those published sooner (which I’d love to see as the earlier we can publish that the better, but we’ve never been particularly good at that).
        
        David Baumwald 5:28 pm on June 23, 2022
        
        Agree with @ jeffpaul . What is a bug bug 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. is mostly well-defined.
        
        As for moving the dev notes dev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. deadline, I appreciate the difficultly, but this would require a proposal in and of itself to update the handbook _before_ implementing.
        
        Héctor Prieto 5:35 pm on June 23, 2022
        
        Thanks for following up, both!
        
        To clarify, I am not proposing any change to the Dev Notes deadline because of the reasons you rightfully mention; I’m only suggesting that a shorter Beta Beta 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. period could help a formal proposal to change the Dev Notes deadline, as I agree with Jeff it’s rather difficult to get the Dev Notes published in time.
        
        More feedback is welcome 🙂
- Tonya Mork 5:43 pm on June 23, 2022
  
  The past couple of cycles(5.9 and 6.0) had three scheduled, with a fourth sometimes scheduled as “optional’.
  
  5.9’s schedule was for only 2 betas. After the decision to delay 5.9, more betas and RCs were added due to needing more time to ship the features.
  
  I have concerns that we’re not allowing for enough time for strictly bug bug 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. fixing after a Beta Beta 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. has coalesced.
  
  Bug fixing shouldn’t be restricted to only in the beta cycle. It’s something that happens throughout the entire alpha and beta cycles. It could be included as bug scrubs during alpha.
  
  I’m not convinced that broad testing and feedback (from outside of the project and active contributors) really happens during beta. From what I’ve observed, that starts in RC 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) . when the codebase stops changing. Up until RC, the codebase is actively changing.
  
  I’m interested in exploring a shorter beta cycle. I think 2 betas is a good place to start (as originally planned in 5.9). That said, close monitoring should happen to observe and gather the impacts and benefits for reflection and further planning. It would interesting to find out if the beta cycle is yielding expected (needed) benefits.
  - jeffpaul 6:52 pm on June 23, 2022
    
    So I think what you’re describing is how things used to work before the introduction of the Feature Freeze phase. Though in any case I’m open to iterating on process as long as we’re clear on describing what it is we’re attempting to learn so we can measure against that afterward to see if the change helped or not (and thus continue with or not for future releases).
  - David Baumwald 6:59 pm on June 23, 2022
    
    Thanks. You and I have discussed that very little testing happens until very close to the finish line. My point was is that with a beta Beta 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. , there’s an announcement and a release that does increase testing over alpha. I also realize bugs can go in anytime before RC 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) . . The bugs that I am worried about are features that go in during alpha, not long standing bugs.
    
    Given the changes to the schedule in 5.9, there’s direct, recent experience that _maybe_ a shorter beta is risky.
    
    I tend to lean the other way. If core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has had issues with feature deadlines(web fonts, FSE templates), I think it’s probably a good idea to keep more beta time versus alpha time. Shorter alpha helps with the “Deadlines are not arbitrary” philosophy.
    
    I’ve actually been in favor of shortening the cycle overall, but I believe these things should be proposed and discussed first(in public so everyone can participate).
Jonathan Desrosiers 2:29 pm on June 23, 2022

I am interested and available to help with 6.1. Release Coordinator, Core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Lead, and Core Triage triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. are all positions I’d be able to contribute!
- jeffpaul 4:07 pm on June 23, 2022
  
  Happy to help co-lead on any of these as well, but also happy to help with someone else newer to a release team that would co-lead on these and I can assist in the background to give someone newer a “safety net” as they work through the major release major release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. cycle.
Héctor Prieto 3:03 pm on June 23, 2022

Just noting that I would love to repeat as co-release coordinator buddying with somebody else, but I won’t be available to do it alone.
- annezazu 3:23 pm on June 23, 2022
  
  I’d be game for another edition of Anne & Héctor co-release coordinating. Unless someone else wants the experience, count me in.
- Miguel Axcar 5:51 pm on June 23, 2022
  
  I would be glad assuming this responsibility counting on Héctor’s support :0)
ifelserun 5:24 pm on June 23, 2022

Love to help(ETL, Testing)
Dan Soschin 5:24 pm on June 23, 2022

I’d like to nominate Jonathan Pantani – @ jpantani for mar/comms lead (I will gladly backstop, assist, and knowledge transfer)
- Jonathan Pantani 8:45 pm on June 24, 2022
  
  Absolutely count me in!
Femy Praseeth 5:33 pm on June 23, 2022

I am interested in being part of the Docs team and working on the End user docs.
Nick Diego 6:36 pm on June 23, 2022

I’d love to repeat the Editor Triage triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Lead role. As this role was added after 6.0 was already started, it would be fun to run this role from the very beginning of 6.1. There are still a lot of processes to standardize and develop around this role that I would like to help build.
- annezazu 9:58 pm on June 23, 2022
  
  If you wanted a co-lead, I’d also be game to help here. No worries if not (truly, it would give me more time to help with the outreach program). I find I end up naturally gravitating towards a combo of core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor triage triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. , test, and perhaps now RC 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) . work 🙂
Hendrik Luehrsen 9:50 pm on June 23, 2022

If we can gather the resources for a new default theme I would love to see something neutral, which is very extensible Extensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. . The last few default themes were very opinionated and working in the old themes made me remember how much I liked Twenty Seventeen and Twenty Nineteen.

I would also make that theme as stable and as extensible as possible. No beta Beta 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. features, to show the best practices and stability we have in the block Block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.

That would IMHO do a lot of bloggers and business a big service.
- Jessica Lyschik 10:26 am on June 24, 2022
  
  I‘ve mentioned this on Twitter already, I‘m surprised that there seem to be no plans for a new default theme for the final major release major release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of this year.
  
  As Hendrik mentioned, a basic theme that shows off what‘s possible and is easily extendible would be a nice addition to the default themes.
  
  So my question is, is there anything planned or is there a reason that the default theme has not been put on the agenda for 6.1?
ironprogrammer 12:30 am on June 24, 2022

I’d be happy to serve as Test Lead (or co-Test Lead) 🙌🏻.
Ahmed Chaion 3:25 pm on June 24, 2022

Continuing with my role as part of the Triage triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Team is something I wish to offer. Especially taking responsibility for the APAC time zone to be precise. Would love to be a part of the release squad. Thanks!
Birgit Pauli-Haack 6:02 pm on June 24, 2022

I’d be happy to serve as documentation co-lead on the 6.1 and continue working on the processes.
- Simon Kraft 9:37 pm on June 24, 2022
  
  I’d love to chime in with documentation as well!
- Michael Burridge 4:28 pm on June 28, 2022
  
  I’d also be happy to work on documentation along with Birgit.
marybaum 4:15 pm on June 26, 2022

I’d be happy to help as marcomms lead or co-lead, or design co-lead. Thanks!
Paul Biron 8:58 pm on June 29, 2022

I remember some discussion in the past (I think there was a make/ core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. post…but not positive) about shortening alpha and lengthening beta .

I also don’t remember the outcome of that discussion, but I think it’s worth considering.
- Paul Biron 8:59 pm on June 29, 2022
  
  Opps, meant the above to be a reply to @ davidbaumwald ‘s first comment.
Akram Ul Haq 6:20 am on July 1, 2022

Just count me in and I will chime in for the documentation part … let’s move on …. 🙂
Milana Cap 12:15 pm on July 1, 2022

I’d love to help with docs
justlevine 7:33 pm on July 4, 2022
Echoing what @ pbiron pointed out below, what about the existing discussions/feedback?
- https://make.wordpress.org/core/2021/02/11/making-wordpress-releases-easier/
- https://make.wordpress.org/core/2020/10/29/discussion-align-the-wordpress-release-cycle-with-the-industry-standard/
Those are off the top of my head, but I’m sure there’s been more.
Mike Schroder 6:23 pm on July 6, 2022

Hi!
It’s been a little while since I’ve helped out on a release squad, but I’d be willing to give it another go this time around, if it’s appreciated.

Could help out with Core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech, Triage triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. (had a lot of fun helping with this in 6.0!), or other coordination if it’s desired — especially if it could be of help in APAC. My preference would be to do any of the roles along with another person.

As it seems there are a lot of volunteers this time, happy to do so another time as well.
Jb Audras 9:57 pm on July 6, 2022

Hello and thank you for putting this agenda together.
I’d be happy to help on Docs, Triage triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. or Core Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. tech.
The release planning looks great to me and also, I’m up to continue running bug bug 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. scrubs each week until the Triage coordinator is nominated.
Rich Tabor 6:46 pm on July 21, 2022

I’d be down to jump on Design Lead.
Michal Czaplinski 4:41 pm on July 22, 2022

I’d be happy to help in the Editor Tech role! 🙂
- Bernie Reiter 8:51 am on July 25, 2022
  
  I can serve as backup/co-lead alongside Michal 🙂
jeffpaul 8:26 pm on August 31, 2022

Note the updated v2 post here: https://make.wordpress.org/core/2022/07/26/wordpress-6-1-planning-roundup-v2/

Comments are closed.

Welcome!

Communication

Proposed WordPress 6.1 Schedule

Proposed WordPress 6.1 Release Leads

Join The Squad!

Share this: