Minor releases (X.Y.Z+1) are WordPress releases that fall between major releases (X.Y+1) providing 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. fixes, small, self contained enhancements, and security fixes when appropriate. Minor versions are released as necessary. The current cadence is one every 4-6 weeks.
Since WordPress 3.2, minor releases have been released (on average) every 5 weeks after another major or minor 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.. This cadence has increased slightly since WordPress 5.0 to an average of roughly every 4.5 weeks.
Pain points
With the minor release cycle, there are currently several pain points that make planning and executing difficult.
(Much) Shorter release cycle
The shorter release timelines for minor releases enable faster iteration on features included in major releases, and allows important bug fixes to be delivered to users faster. Which is great! However, it makes other parts of the release cycle, such as compiling a release team, much more difficult (this process can sometimes take up to 2 weeks).
The real work for a release does not fully commence until after a release team is assembled. This results in minor releases having even less time for actual work than they should (2-4 weeks instead of 4-6).
Unknown scope
While minor releases focus only on bug fixes and small, self contained enhancements, some have a smaller, more targeted scope aimed at a more specific area of the code base.
For example, if Feature A is included in the X.Y 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., the scope for the X.Y.1 minor release may be aimed at polishing the user experience of Feature A. It can sometimes take 1-2 weeks to determine whether a more targeted scope is required (this is dictated by the incoming support and ticket Created for both bug reports and feature development on the bug tracker. volume).
Contributor focus
Oftentimes, minor releases are organized and executed by contributors that are also working on tickets, tasks, and features for the next major release. This can lead to divided attention and focus spread out between too many items.
Additionally, when the date of an upcoming major release is nearing, it can cause a longer than usual gap when the attention of these contributors shifts fully to the next major release. For example, 5.4 was released nearly 15 weeks after 5.3.2. While this is the longest gap since 5.0, it’s not uncommon for a major release to be released 8-12 weeks after the last minor from the previous branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". (the average since 5.0 is nearly 8 weeks).
Though as many contributors as possible should focus on testing the next major release, there should not be a huge gap. Having a small team focused solely on minor releases will hopefully help shrink that gap while allowing other contributors continue to focus on the next major release.
Security
Occasionally, a minor release will include fixes for security vulnerabilities. These releases happen under a few different conditions:
- There are enough security fixes to push out a minor release solely containing security fixes.
- There is a minor release already planned and the security team is able to have fixes for known issues prepared.
However, it’s difficult for the security team to plan and coordinate when minor releases will occur and, due to the issues mentioned above, know who to coordinate with.
Consistent minor release leads
For the upcoming 5.7.x releases, a release lead The community member ultimately responsible for the Release. and release deputy will be named for all 5.7.x releases, and will serve until 5.8 is released.
These two contributors will be responsible for:
- Publishing timelines and plans for each minor release.
- Executing these plans through release day.
- Coordinating with the Security Team lead to improve the flow of fixes from the team to users.
- Assembling and requesting help from other volunteers for each release as deemed necessary (docs, test, specific focus areas, etc.).
Ideally, one of these two contributors has a technical background (with the abilities to identify, confirm, test, and approve bug fixes and changes), and the other has a project manager or coordinator background (with the abilities to create release timelines, coordinate contributors, and help unblock efforts).
One additional (potentially optional) criteria would be that either the lead or deputy be a part of the previous major release’s squad, or be very familiar with the changes that were introduced in that major release. This would further increase the speed at which the minor releases are able to fix related bugs, as they are already “up to speed” on the changes.
In recent years, the gap between major releases has been, on average, 3 to 5 months. If necessary, contributors can tag 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.) in and out of the role should circumstances change and it becomes necessary.
The hope is that by eliminating the need to plan each and every minor release from scratch, the actual time contributors have to work on active bug fixing, triaging, testing, etc. will be increased, allowing minor releases to deliver fixes to users more quickly and effectively.
If this works and the decision is made to continue this practice into the 5.8.x releases, the next two contributors should be named prior to 5.8’s final release to ensure a smooth transition.
Volunteering
If this is something you are interested in and you anticipate having the bandwidth for the next 3-4 months, or if you will be available to help our for the 5.7.x minor releases in other ways (triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., documentation, etc.), please feel free to comment below!
And of course, questions and feedback are always welcome!
Props @chanthaboune, @jeffpaul, @cbringmann, and @davidbaumwald for peer reviewing.
