Hey, this is a good topic to discuss. We have talked about parts of this process here and there, and we agree that the time between a merged change and an official release can sometimes feel too long.
Short answer: yes, we should keep improving the cadence, especially for clear regressions and low-risk fixes. Smaller, focused patches can make sense. Narrower RCs and quicker follow-up RCs can also help users test ready work sooner. At the same time, major or riskier overhauls and modernizations need more time for feedback, iteration, compatibility work, and validation before they become stable. That inevitably slows the release cadence. Even then, while we address feedback, we try to include compatible, low-risk improvements in an ongoing beta when they fit its scope and do not make validation harder.
What sets the current pace
The main constraint is capacity. Across the three developers working on Meteor core, we have roughly 2 to 2.5 full-time capacity. That covers implementation, reviews, testing, support, documentation, release preparation, community follow-up, meetings, recordings, articles, ideation, cross-area compatibility, and cross-OS support and validation.
AI does help us move faster. It can investigate old issues, produce focused fixes, implement changes, and add tests quickly. That is genuinely useful. But it is also a double-edged tool.
Code volume is no longer the main limitation. Review capacity, confidence in a change, follow-up ownership, specialist knowledge, CI time, and real-world validation do not grow at the same rate. AI can produce a plausible answer to an issue, but it cannot by itself tell us whether that answer is safe for a legacy flow, compatible with the current architecture, still relevant to the roadmap, or likely to create integration issues in other untested or fragile parts of Meteor. We still need people who understand an area to make those calls.
A release is also a feedback cycle
Releasing is not especially hard by itself, and we have automated a lot of it. But it is not just pressing a button either. Each release needs a considered scope, changelogs and documentation, CI and E2E review, testing in examples and Cloud-related flows, and confidence that it is in good shape for real projects. When everything goes well, that can still take a full work day.
Release planning starts before a beta and continues while it is being tested. We define each beta’s scope before, then use its feedback window to triage, integrate, and validate the planned, compatible contributions for the next beta. This lets us prepare the next release without weakening the test focus of the beta already under test.
Historically, we have used the Meteor 3.x minor releases to keep focus on larger modernization work, including the bundler, Change Streams, and other architectural changes. Patches have mainly been the way to respond to feedback and regressions after those changes reach larger production applications.
This focused, iterative approach is how we have been able to deliver much of Meteor’s recent modernization despite limited capacity and a period of uncertainty for the project. Much of that work began before AI-assisted development made implementation and experimentation faster. Today, AI certainly helps us produce and evaluate more work faster, but the quality of delivery still depends on sustained technical planning, execution, and validation, rather than simply increasing the amount of code we can produce.
We also try to leave enough time for betas. That is not because we want changes to sit around unnecessarily. It is because the beta period gives people time to test, report problems, and help us fix them before an official release. We want to ship quality, not only quantity.
For us, release cadence is not only about how quickly we can publish a version. It is also about creating a useful feedback cycle: make a focused change available, give people enough time to try it in real projects, understand the feedback, and use that feedback to prepare the next release. Different teams adopt at different times, so some issues will only appear after a beta or an official release reaches a wider audience. A healthy cadence should make room for that learning without letting every release grow into an unrelated batch of work.
We have tried running releases in parallel as well. Meteor 3.4.1 and Meteor 3.5 had betas around the same time. In practice, that created more conflicts between versions, more release work, and less focus for roadmap priorities and community reviews. AI can help with some of that work, but it does not remove the need for specialist review or coordination.
At the same time, keeping a beta focused on a defined set of changes gives us a stable target for isolated testing and debugging. For example, the first Meteor 3.6 beta can focus on Rspack 2.x rather than combining many unrelated changes in the same beta. That focus also makes it easier to identify which changes cause regressions and fix them quickly. This is especially important when a minor release contains a platform-scale overhaul, as several recent Meteor minor releases have done. In those cases, the scope and compatibility risk can be closer to a future major release than to a routine patch.
What we are trying to improve
We agree that we should distinguish more clearly between a well-understood, low-risk patch and a larger feature release. We should keep releases focused, avoid letting unrelated work block a clear fix where possible, and make it easier to prepare a follow-up RC when beta testing finds a problem.
A predictable cadence is useful when the release scope and validation capacity support it. For the Meteor 3.5.x series, we are aiming for a roughly three-week cycle when conditions allow it: one week for implementation, triage, merging, and wrapping up ready candidates; one for beta validation; and one for the official release. That is a target, not a promise. We would rather keep that cycle focused and reliable than promise a weekly or biweekly schedule that creates more parallel branches, conflicts, and release overhead.
Meteor 3.6 already has material ready for its first beta, including Rspack 2.0 work, and it will follow Meteor 3.5.2. We are avoiding parallel releases again because they can end up delaying both versions. There is also important work already implemented and waiting for future releases, including the CapacitorJS beta.
We also think the cadence will improve as we complete the major platform overhauls that still need focused attention, including native support, TypeScript, and testing infrastructure. Those efforts require concentrated technical time for planning, implementation, testing, compatibility work, and validation. They should not be rushed simply to increase release frequency. The goal is to turn that work into stable, well-understood processes that provide lasting value for Meteor. As we complete those larger efforts, we will have more room to accelerate smaller, focused releases without compromising the quality that makes the framework dependable.
Earlier validation and community help
We also want to encourage developers and testers to work from Meteor checkouts when they want to try an ongoing change before an official or even a beta release is available. For example, we plan to provide clear instructions for experimenting with CapacitorJS before it reaches beta. That is not a replacement for stable releases, but it can give contributors and maintainers much faster feedback.
We also understand that waiting a long time for a merged contribution to reach users can be frustrating. Early validation through checkouts and betas can help contributors see the effect of their work sooner, even when a stable release still needs more time and coordination. Not every useful new contribution needs to enter Meteor core immediately, either. A third-party Atmosphere package can be a good way to experiment, publish value independently, and build community validation. It lets contributors move on a cadence that fits their work instead of waiting directly on the core release cycle, while still creating feedback and evidence that can help both the package and a possible future core integration.
Trusted contributors can absolutely help with reproduction, testing, triage, documentation, and validation. The important part is giving that help clear scope and keeping specialist review where compatibility or architectural decisions are involved. Every PR, release candidate, and branch still asks for shared attention, and reviewed code is not automatically ready for an independent release if its compatibility or support risk is still unclear.
Communication also needs to improve. The ongoing governance proposal is an important step, and we hope it helps give contributors clearer paths for discussion, experimentation, triage, and decisions before work becomes blocked in the shared queue. Better communication will help the community support core efforts and make the whole release process more agile.
So we do not think the answer is only “release more often”. It is also about keeping releases focused, reducing unrelated work in the review queue, reaching clear merge-or-close decisions, and using betas, checkouts, and community testing to get feedback earlier.
We are always trying to speed things up, but we also need to be realistic about our capacity. We appreciate the discussion, and we would be glad to keep it open for ideas on which parts of the process we can streamline further without losing the quality and stability people expect from Meteor. Practical support can help across the full path from contribution to release: reproduction and triage, proportionate test coverage, CI validation, integration with the latest deliveries, documentation, E2E coverage where needed, local-checkout testing when the change requires it, and cross-OS validation.
Whether it’s a business or hobbyist development, “move fast, break things” isn’t worth the headache for a lot of people.
