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 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/ plugin 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 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 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 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 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.
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 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 Core 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 (RC 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 blog (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, Trac 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, `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.` 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!