Jonathan Desrosiers 8:10 pm on February 27, 2019

Major and Minor Version Release Cadence

A recent devchat discussion questioned what the release cadence for major and minor releases should be moving forward. A handful of positive and negative factors for different release timelines were discussed that should be considered while determining targets and goals for the release cadence of the project long-term.

This post will be a bit retrospective, detailing some past release practices, as well as collective, summarizing the devchat discussion mentioned above to encourage thought and constructive feedback.

5.0.x Release Cadence Summary

During the 5.0.x version lifespan, some experimentation was done with shorter timelines for minor releases. Releasing closer to every two weeks better matched the GutenbergGutenberg 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/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party cadence. This let users receive the latest, stable code for the new blockBlock 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 and delivered the best experience possible.

Summarizing these releases is a great way to start the discussion about shorter release cycles in general. With that in mind, here is a breakdown of each release in the 5.0.x version with timing relative to the 5.0 major releasemajor 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..

Date	Version	Type	Timing
December 6, 2018	5.0.0	Major	—
December 13, 2018	5.0.1	Minor (security)	+7 days
December 19, 2018	5.0.2	Minor (maintenance)	+13 days
January 9, 2019	5.0.3	Minor (maintenance)	+34 days
February 21, 2019	5.1.0	Major	+77 days

Note: After 5.0.3 was released, the 5.1 release schedule was announced and further planned minors for 5.0.x were stopped.

Looking back, sticking to a 2 week release cadence for minor versions was successful with the following considerations:

5.0.1 was a security release that was independently planned by the security team.
The gap between 5.0.2 and 5.0.3 was 3 weeks, but that includes 1 week to account for major holidays.
A larger time period between 5.0.3 and 5.1 is expected due to major releases having a longer BetaBeta 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.

Since the 5.0.x series was generally successful using 2 week release timelines, WordPress 5.1.1 is planning to follow this same cadence.

Past Major Release Cadence

Another past release cadence that’s worth mentioning for historical context was followed from version 3.9 through 4.7. Each of these major versions were released between 3 and 4.5 months apart from each other. This is a cadence that is commonly mentioned when establishing a regular release cadence is brought up (including during the devchat mentioned above).

Those present at the devchat mentioned were generally in favor of a more regular release pattern. The main reason mentioned in favor of more regular release schedules is predictability. When the timing of major releases are more predictable, component maintainers, support forumSupport Forum WordPress Support Forums is a place to go for help and conversations around using WordPress. Also the place to go to report issues that are caused by errors with the WordPress code and implementations. volunteers, and users are better able to plan their time.

Shortening Major Releases

During the devchat mentioned above, @youknowriad proposed shortening major release cycles for WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to around one month.

The Gutenberg plugin has been adhering to the following schedule:

Release a plugin version every two weeks (RCrelease 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). on Monday, final on Wednesday)
Release all the features that are ready at that moment, and postpone any remaining to the next releases automatically

At the level of the Gutenberg plugin, this has resulted in the following:

Less stress for contributors
Predictability: People can plan around the release timelines easily
No delays as releases are not feature-based

Monthly major version releases might be an achievable long-term goal. But, there are currently too many manual tasks associated with releasing a major version of WordPress that need to be documented and automated wherever possible before being considered.

Manual Tasks

Here is a rough list (in no particular order) of some time consuming manual tasks required for every major version release of WordPress:

Organizing the release schedule and scope.
wordpress.org/news release blogblog (versus network, site) post, as well as beta and RC posts.
Field Guide
Writing and organizing detailed “dev notes” for changes users should be aware of
An About page needs to be designed (and sometimes illustrated), developed, and tested.
Sometimes, a video needs to be planned, designed, and created.
Codex/HelpHub pages need to be written, created, and linked to appropriately.
Historical pages/release timing pages are manually maintained.
Bundled themes need to be versioned and released if they contain changes.
Tickets are often optimistically placed in milestones, TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. gardening requires a significant amount of time.

This list is by no means all inclusive. Recent major version release leads (mainly @pento) are working to document all manual tasks that are required before a major version of WordPress can be released. The Releasing Major Versions page of the WordPress Core Contributor Handbook has a more detailed list of tasks, but even this is incomplete.

Pros

If major release timelines are shorter, fewer large features would be shipped in a single release. This would:

Less drastic change between releases, which should spread out burden of update support.
Make it easier for users to keep up with changes since there would be fewer.
Make more people comfortable with enabling automatic updates for major releases.
Shorter, more frequent major releases would potentially make versions less “important” (updates could just happen seamlessly, such as with Chrome).

Cons

A large majority of contributors are volunteers contributing in their spare time.
There are many non-code contributions required for a successful release. Many of which cannot happen during the development process.
Plugin and theme developers need reasonable notice of technical changes in case they need to push out a compatibility update.
Without the ability to opt-in to automatic major updates, there is the potential for users to “burn out” from an increased number of releases.
Security releases would require significantly more backporting work.

Some Challenges

WordPress has typically been developed one release at a time while larger features are built first as plugins. For example, during the 5.1 Beta/RC period, `trunktrunk 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.` remained closed for 5.1.1 and 5.2 tickets.

Feedback

What are manual tasks associated with a major release you are aware of that should be documented? What are some advantages and disadvantages of shorter (or longer) release timelines you want to call out? What are potential challenges and obstacles that need to be considered when moving towards shorter major release cycles? Please share and discuss in the comments below!

Paul Gilzow 8:24 pm on February 27, 2019

Make more people comfortable with enabling automatic updates for major releases.

You seem to be forgetting the group of users who use WordPress in a business/professional setting, who can’t risk automatically installing new feature sets (major releases) that may break their production siteProduction Site A production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing. without notice or warning.
- Jonathan Desrosiers 8:50 pm on February 27, 2019
  
  There will always be segments of users that will choose not to utilize certain features and functionality within WordPress. That is merely being mentioned as a potential positive side effect of shorter, smaller, more frequent major releases. More users automatically running the latest version of WordPress (or any software) is a positive thing.
  
  Making it easier for users to opt-in to automatic major updates is one of the 9 Projects for 2019. This is a potential way to help make this a more positive experience for the users that choose to opt-in to that feature.
binarymoon 9:04 pm on February 27, 2019

I am not involved with the WordPress release process, but is there a reason it has to have this many manual changes?

I am probably sticking my nose where it doesn’t belong – so feel free to ignore me but …

I’m a fan of keeping things simple and reducing manual work. If this were a project I was running then I would be thinking the following:

Organizing the release schedule and scope.
Tickets are often optimistically placed in milestones, TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. gardening requires a significant amount of time.

No delays as releases are not feature-based

If it moves to a GutenbergGutenberg 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/ style system could these be reduced? Just tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) tickets that are going to be in a release when they are ready rather than planning the release before hand?

Note: I don’t know how tagging is used in Trac so this may not be practical

Another note: I love reading the fieldnotes so please keep them! 🙂

Field GuideField 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.
Writing and organizing detailed “dev notesdev 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.” for changes users should be aware of

These appear to be the same thing. It seems to remove a bullet point at least 🙂

wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//news release blogblog (versus network, site) post, as well as betaBeta 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. and RCrelease 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). posts.

An About page needs to be designed (and sometimes illustrated), developed, and tested.

Can this be an edited version of the field notes?

Can we simplify the about page? Does it need to be so elaborately designed? If it was a gif with some bullet points of the major features it could use a lot less design. In fact the release post could be copied and pasted into the about page or even pulled in from the blog through the rest apiREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.?

Sometimes, a video needs to be planned, designed, and created.

Does it need to be done?

If we keep them then reduce the production values. The short videos that are done for Gutenberg are great – I don’t think anything more advanced is needed, and I don’t imagine they take very long.

Codex/HelpHub pages need to be written, created, and linked to appropriately.

Can this be an edited version of the fieldnotes? Or even just a link to the fieldnotes blog post?

Or do you mean documentation for new features? In which case I’d suggest this doesn’t need to hold up the release schedule.

Bundled themes need to be versioned and released if they contain changes.

If the themes are developed well (which I know they are) then they won’t break when a new version is released. I would suggest this doesn’t need to hold up the release process.
- binarymoon 9:05 pm on February 27, 2019
  
  oh – the notes on the tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets are referring to the field notes. Not the trac tickets.
- Jonathan Desrosiers 10:07 pm on February 27, 2019
  
  Thank you for all of this feedback. You had a lot of great questions and thoughts. I did my best to explain as many as I could!
  
  I am probably sticking my nose where it doesn’t belong – so feel free to ignore me
  
  Your feedback is equally (if not more) valuable as you provide an outside perspective. Sometimes, those most closely involved miss things because they are just too close to the existing processes!
  
  is there a reason it has to have this many manual changes?
  
  The short answer to this is that as WordPress has grown, many new parts were added to the process or have become necessary. In some cases, these items still need documentation. They have not been automated because they either require a person to manually work on them, or that they have just not yet been automated.
  
  If it moves to a GutenbergGutenberg 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/ style system could these be reduced
  
  As far as I know, the Gutenberg team still manually does this. The equivelant in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ is just different. Deciding what goes into a milestone requires human interaction to make a decision about whether something is fits the scope, is tested well enough, and will not cause any unintended consequences.
  
  Field GuideField 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.… Dev notesdev 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.… These appear to be the same thing.
  
  These are actually two separate manual tasks. The dev notes are detailed technical posts targeting a specific change. The field guide is a separate post that also requires writing and curation.
  
  wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//news … About Page
  
  These have similar information, but they each have very different targeted audiences and often require different tone and levels of detail.
  
  simplify the About page
  
  If releases are shortened/made more targeted, then this could potentially happen organically. Less change would be included in each major releasemajor 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., and the amount of work would be decreased.
  
  Codex/HelpHub pages need to be written…Can this be an edited version of the fieldnotes
  
  Same as above, these resources have different audiences than the fieldnotes.
  
  That said, I do think there is opportunity to automate parts of these. For example, the modified file list, or updated packages lists. This could be automated and distributed to all resources.
  
  If the themes are developed well (which I know they are) then they won’t break when a new version is released. I would suggest this doesn’t need to hold up the release process.
  
  Many times, these updates are related to ensuring that the default themes have maximum compatibility with the latest version of WordPress, including support for new features being shipped in that version. These updates need to be coordinated to coincide with the release of the appropriate major version.
Jeremy Felt 9:46 pm on February 27, 2019
Today’s dev chat had some discussion around when to assign a release leadRelease Lead The community member ultimately responsible for the Release. for minor releases. I think getting to a shorter release cycle in general will involve scheduling multiple releases and assigning their release leads in advance. So far most of our scheduling is done as soon as the last release has been shipped.

The Firefox project has an interesting release owner table that assigns people and dates for several releases – https://wiki.mozilla.org/Release_Management/Release_owners

Of note:
- Several releases in advance have a primary and secondary owner, even if they do not have an exact release date scheduled.
- Each release has a “Regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. Engineering Owner” assigned, which is probably our equivalent of a minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. lead.
- I think (assume) that the column for “Release Duty” is probably our equivalent of the “person actually committing version bumps, hitting release buttons”.
Robert Anderson 10:46 pm on February 27, 2019
In the long term, I would like us to embrace continuous delivery and move to a model where:
- Releases are frequent and regular, e.g. the first day of every month.
- Releases are semi-automated, e.g. we develop tools and processes to reduce the amount of manual work involved in a release.
- Releases are not tied to particular features, e.g. using feature flagging. This should alleviate any pressure on contributors to “develop software faster”.
- Releases are well tested externally using different release channels e.g. a stable channel (current major), a betaBeta 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. channel, and a nightly channel.
- Releases are well tested internally through improved tooling, e.g. continuous integration on each ticketticket Created for both bug reports and feature development on the bug tracker..
In the short term, a quarterly cadence feels right to me 🙂
Riad Benguella 7:29 am on February 28, 2019
Thanks for the post Jonathan. While I’d love us to go into the path of the continuous delivery model, I agree that it’s not immediately actionable.

By looking at this list of manual tasks, it feels that if we want to invest in a shorter release cycle, there are some ideas we could explore to automate or “change” some items in that process:

– Organizing the release schedule and scope.

We saw in the recent 5.1 when we removed a feature (Part of Health Check) that even if we plan features and scope ahead of time, it is not always wise to tie these to a particular release. An alternative workflow would be:

– Have a mid-term direction (similar to the 9 projects post).
– Work on these on branches or behind feature flags.
– Ship them when ready.

(By the way that’s very close to the GutenbergGutenberg 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/ way of releasing features)

– wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//news release blogblog (versus network, site) post, as well as betaBeta 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. and RCrelease 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). posts, Field GuideField 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., Dev notesdev 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., About page, HelpHub.

All of these are important but on a continuous delivery model, I think these could be rethought a little bit, because with a smaller release, the difference between some of these writings will be less important.

One way to make this less of a burden, is “Documentation as code”. I know this is a very big change on its own, but it has a lot of advantages:

– The documentation is ready beforehand, when the feature is merged.
– The documentation is up to date and tied with the versions it’s written in
– The devnotesdev 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., field guide… will all have some material ready to be adapated.
– The about page has probably a different meaning in a shorter release cycle, it can’t be only about the features from the last release, there’s probably some automation there too.

– Historical pages/release timing pages are manually maintained.

This seems like it can (and should) be automated

– Tickets are often optimistically placed in milestones, TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. gardening requires a significant amount of time.

This is related to my first point, in a continuous delivery model, triaging is also continuous but has no impact on the release as when the date of the release comes, the remaining items are automatically moved to the next release.
- Release day
I noticed during the release process, we have a dozen of people around to help and it can last a few hours depending on the release. I don’t have all the answers but it feels like we’re waisting contributor time for me. An interactive script to follow the steps could help, when manual items are needed, suggestions can be made. Manual testing is good and always necessary but automated testing is way better to gain confidence in the release process, it’s a big investment.

I’m well-aware that any of these changes is a big project on its own and we may not have the resources to tackle these, but happy to see this discussion happening.
- Jonathan Desrosiers 4:32 pm on February 28, 2019
  
  Thanks for commenting, @youknowriad!
  
  All of these are important but on a continuous delivery model, I think these could be rethought a little bit because with a smaller release, the difference between some of these writings will be less important.
  
  Totally agree here. These become a bit less of a burden when releases are smaller. I see them becoming much more feature focused (which can, and already do with dev notesdev 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., happen separately from the release) and less release focused.
  
  the remaining items are automatically moved to the next release.
  
  There has been a bit of trouble with this a few times before, where the number of tickets being moved from milestone to milestone is too large (see this post). It became impossible for contributors to know where to focus their efforts. GutenbergGutenberg 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/, I believe (correct me if I’m wrong), only allows a few focus leads place issues into milestones. In TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress./CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., component maintainers are free to do this where they see fit.
  - Riad Benguella 4:42 pm on February 28, 2019
    
    > GutenbergGutenberg 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/, I believe (correct me if I’m wrong), only allows a few focus leads place issues into milestones. In TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress./CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., component maintainers are free to do this where they see fit.
    
    Gutenberg allows a number of contributors to place things in milestones but the milestones have different meaning.
    
    There are issue milestones and PR milestones.
    
    Issue milestones:
    
    We have three levels (WP 5.1.x, WP 5.x and future). This means there are issues that are considered very urgent (the “5.1.x” corresponds to the bugbug 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. fixes needed for the next milestone).
    
    The 5.x are actionable items we want for the next WordPress major releases based on the expressed goals by the leadership (9 projects) and some manual arbitration by the contributors.
    
    The future milestone are things considered low priority or good but not an immediate focus.
    
    PR milestones:
    
    (4.9, 5.1, 5.2 ….) are used to indicate the milestones in which the PRs were merged (released), it’s useful after the fact to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. PRs included in a particular Gutenberg release.
    
    When I say the remaining items are moved to the next milestone, I’m talking about PRs (not important to triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.).
    
    So I guess the main difference is that the issue milestones are not used to say what “must” go into a release, they’re are just higher-levels of priority and the freedom is given to the contributors to work on these (with coordination during the weekly chats).
Joe McGill 4:26 pm on February 28, 2019

First off, I’m very much in favor of us having a more regular release cadence. The pre 5.0 release cadence was nice, in that it allowed us to plan and execute features on a regular bases, but there was a lot of unnecessary overhead that I think could be reduced that would allow us to have more frequent releases.

In light of these discussions I looked at other OSS projects for inspiration and came across the development process documentation for VS Code. The process they outline is very similar to the one I would like to see WordPress adopt. Without going into too much detail, the high level outline of what I like about their process is the following:

1. A long term roadmap (theirs is 6–12 months) outlining major themes and features.
2. A monthly release cadence based on 4 week sprints which begin with milestone planning and always results in a release of whatever was completed in that monthly iteration.
3. Regular project triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., with release priorities managed at the team (i.e. Component) level.
4. Documentation integrated into the development process.
5. Automated testing of releases and upgrades.
6. Only important regressions and security issues are handled in minor releases between monthly milestones, everything else is moved forward to the next release (or reprioritized in the backlog).

If we don’t have the infrastructure and tooling to support a 1 month cycle, then I think we could attempt a 2 month cycle with a goal towards moving to shorter cycles.
edanzer 6:02 am on March 1, 2019

While I do definitely understand the advantages of shorter release cycles, I’d also like to add a note of caution. It’s quite possible that rapid releases will produce fatigue for both normal users and the third party developer ecosystem.

This post implies that rapid releases would be safer because they are smaller. I don’t think that the post 5.0 release experience supports that assertion.

Stability and backwards compatibility have traditionally been major strengths of WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. releases. One could make the case that in the interest of more rapid forward progress – admittedly good for the future of WordPress – core releases starting with 5.0 have been somewhat less careful about backwards compatibility (and ‘sideways’ compatibility with the ecosystem).

The 5.0 release itself was great but also produced a lot of dislocation that users and the developer ecosystem aren’t close to recovering from. Subsequent releases have also produce some significant breakage, especially given how quick they’ve been.

My guess is that the nature and pace of change in the GutenbergGutenberg 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/ era will continue to mean less stable releases overall compared to the past. And if you combine rapid releases with less stability, it’s easy to see how that combo could become a recipe for frustration.

That’s not to say rapid releases can’t work. But I hope that if we do move toward this kind of pacing, we’re also attentive to the potential costs and try hard to alleviate those.