Release cadence discussion

core
7

Thanks for the detailed explanation, @nachocodoner . I agree with your assessment, especially regarding our current capacity and the additional review and validation work created by parallel releases.

I think we already have a good release process and have learned a lot from the recent cycles. I am not proposing a major redesign, but I see a few areas where we could structure the existing process more clearly and improve it through small, targeted adjustments.

Release documentation

We already have parts of the process documented:

However, we still lack a single end-to-end operational runbook covering topics such as:

  • Responsibilities and ownership
  • Scope and prioritization decisions
  • Patch and backport rules
  • Required tests and validation
  • Branch synchronization
  • Entry and exit criteria for each release stage
  • Communication with contributors and the community
  • Recovery steps when something goes wrong

Much of this knowledge is currently fragmented or implicit. Consolidating it would reduce our dependency on tribal knowledge and make it easier for other contributors to participate in the process.

Patch and feature release lanes

I agree that our previous attempt to run releases in parallel did not bring meaningful benefits. However, I wonder whether the problem was parallelism itself or the fact that two similar release processes were competing for the same limited review, testing, and coordination capacity.

One possible adjustment would be to maintain two clearly separated release lanes.

Patch releases

A patch lane could:

  • Start from the latest stable version
  • Include only regressions, bug fixes, and well-understood low-risk improvements
  • Run more frequently when eligible fixes are ready
  • Use a shorter beta validation period of approximately one week
  • Follow a small and predictable checklist

Feature releases

A feature or minor release lane could:

  • Follow a longer cycle of approximately three months
  • Publish incremental betas throughout the cycle
  • Give the community more time to test larger changes
  • Allow completed features to be tested while other planned work continues
  • Move unfinished work to the next cycle instead of delaying everything that is already ready

The main benefit would be that a completed feature would not need to remain unavailable simply because another feature planned for the same release is still under development.

This would not be entirely new for Meteor

Historically, Meteor has already maintained patch and feature release lines in parallel at different points.

For example, on September 19, 2019, the team prepared both:

The Meteor 1.8.2 release discussion also explicitly mentions that the 1.8.2 line was reaching RC while the 1.9 branch was entering beta.

A similar pattern appeared again in 2020:

The same happened during the Meteor 2.x period. Meteor 2.7.3 had already been released when the older 2.5 line received another maintenance patch:

The preparation and community validation of that older maintenance release can also be seen in this Meteor Forum discussion and its follow-up messages about the 2.5.8 beta and official release.

These examples demonstrate that Meteor has used parallel maintenance and feature lines in practice. They do not necessarily prove that there was a formal, predictable two-lane policy with fixed rules and schedules.

Our proposal would therefore formalize and simplify a pattern that Meteor has used before, rather than introduce an entirely new release strategy.

Improving the current process

Today, because Nacho and I are the main people coordinating releases, patch fixes and larger feature work often become coupled into the same process.

Separating these concerns, with strict scope rules, clearer documentation, and more automation, could help us release low-risk fixes sooner without rushing larger changes or recreating two equally complex release processes.

Again, I do not think we need to replace the current process. I would prefer to evolve what already works through a few practical improvements rather than introduce a large new process with additional overhead.

Learning from other projects

It would also be valuable if people could share concrete examples of how other mature open-source projects organize patch and feature releases, especially projects with limited maintainer capacity.

Understanding which practices work elsewhere, and why, could help us identify small changes that fit Meteor instead of designing a process only from theory.

3 Likes