As we do every Friday, from 3:30PM CEST (2:30PM GMT) me, @alimgafar and @jkuester are covering the weekly news and interesting things from Meteor Community.
This week, we’ll also have a short discussion on one aspect of Meteor’s future. Join us for the show and then join us in the chat/comments and here to further discuss the our discussion topic. 
The topic is:
Should Meteor adopt a release schedule like Node.js?
What do you think?
For reference here is the Node.js release schedule:
I think it is something that we should aspire to, but with clear goals what we want to get out of it.
First thing, I think we need to look at big dependencies that are going to affect us the most (when it comes to releases):
I think Node.js is the only one with regular release structure, so that is going to dictate any Meteor.js release schedule as well (also because of how closely it is tied to it). Since Node.js releases in April, I think we should aim for major release few months after that (though I think latest September). We could also adopt the experimental and stable release cycle, or (at least in the beginning) just do a major release every other year with the stable Node.js version as its base, that will then be maintained for as long as that version of Node.js.
For each new release it would try to get as much as possible current versions of all dependencies (especially those in the bundles). After dependencies the focus for major releases should be to do any breaking changes (if any) and no breaking changes will be allowed for feature or patch releases (exception for security patch). Where possible the packages versions should not have major version bump unless it is a breaking change (to limit the impact). Larger new features should also be reserved for major version releases (mostly for PR reasons, but also to keep a bit better track of possible breaking changes).
I think this will also allow us slow migrations towards other things, add more predictability to the project (especially for companies) and we could copy LTS versions by Node as well.
I don’t think so. The updates should be small and quick.
A favorite quote:
“Shipping is the heartbeat of a software company. Therefore, shipping new code should be as small, as common, as regular, as boring, and as unremarkable as a heartbeat."
It’s not easy but “Release Every Day” vision is about being agile, being in a position where we can respond to changes quickly, and keeping our products always in a releasable state both for core and our own products.
Ohh… I think I just got the point. Do you recommend to follow node.js updates for meteor’s node.js support? And same for important dependencies for mongo etc?
Sorry, I haven’t finished the dispatch yet 
We need to target node at least on the “active” stage of development. That means that the API has been deemed stable.
In terms of release cadence, the following is an example:
The example above gives each major version of Meteor at least 2 years of shelf life.
In terms of releases, MongoDB also releases a major version regularly (if not annually). Therefore, Meteor can also support the current major version of MongoDB by Q4 of every year, giving the team months to integrate new features and remove deprecated functionalities.
Since the backward compatibility range of MongoDB is wide, the new major version of MongoDB can be supported by using the new drivers without integrating new features. This can be done during patch versions.
But integrating new features and deprecating old ones can be done together with major Meteor releases.
I agree and I would like to see more patch releases. @grubba mentioned on my stream that they are working on improving the CI infrastructure so hopefully we see more frequent releases in the future. But for the big parts of Meteor more planning and time is necessary, not to mention making a major bump in them is not desired outside of major releases, especially when there are breaking changes.
Yes, though I wasn’t able to find so far any specific document in regards to regular release day. Still when a major version is cut it should automatically be updated to the latest version together with Node. So that at least for Node and MongoDB we can then have a nice table which documents major versions and which major versions of those two they have.
From what I’m seeing from the release schedule Node.js releases even number releases in Q2. Given that once we start on this release cycle we should have release candidates about the time when the new Node is released (potentially with the experimental release in the meantime), we should be able to release shortly after, but I would play it safe and choose a date in Q3 or end of Q2 for any patch releases from the Node team.
Then we could have LTS versions like Node as well, so one Meteor major version would live, as you said, for about 2 years.
Are we willing to release a version of node with unstable api?
By the way, as indicated in the release schedule page of nodejs:
Production applications should only use Active LTS or Maintenance LTS releases.
Meteor should be targeting the Active LTS release of Node every October
Yes, you are right. MongoDB does not commit to a scheduled release. Business-wise, they have to release regularly because point releases does not make it to Atlas
Fair enough. If it is the Active LTS then we can target it easily November/December or Q1 next year. Since there is the “current” period before we can have beta releases with that and when the time comes switch to the “Active LTS” quiet easily since we had been already testing the major version months prior.
