Thanks to everyone who contributed to this discussion. @zodern raised an important point: teams running Meteor in production need time to adopt a new minor release without losing access to security updates in the meantime.
After discussing the suggestions here and our maintenance capacity, we want to pilot a clearer release model/cadence:
- Quarterly minor releases: aim for one approximately every three months, with incremental betas during that period so the community has time to test larger changes.
- Monthly patches for the current minor: aim for one release opportunity approximately every month for fixes that are ready and validated. This is a window, not a promise to publish a patch when there is nothing ready.
- Security release for the previous minor: A few patch releases can be replaced by a security release. This patch will be applied to the latest release and previous one. Since it’s a new workflow, we will star by supporting only 2 minor releases at same time, it can change in the future.
For example, once Meteor 3.6 becomes stable, it would become the line receiving monthly patches with bug or security fixes. Meteor 3.5 would move to security-only maintenance for approximately three more months. Urgent security fixes would be released as soon as they are ready, without waiting for a monthly window.
In my earlier reply, I suggested patches roughly every two weeks. After considering the review, backporting, and testing involved, a flexible monthly window looks like a more sustainable starting point.
We are starting with the current minor and the immediately previous minor. This is not an announcement of an LTS program or a commitment to maintain every Meteor 3 minor in parallel. We will try the model for a few release cycles, measure the work it requires, and document the precise support rules before treating it as a standing policy.
We would especially like to hear from teams using Meteor in production: how much time do you need to adopt a new minor release, and what makes that upgrade difficult?