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 Gutenberg plugin cadence. This let users receive the latest, stable code for the new block 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.

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 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 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 to around one month.

The Gutenberg plugin has been adhering to the following schedule:

  • Release a plugin version every two weeks (RC 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 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 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` 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!