We have a new roadmap for the Meteor project! You’ll notice it’s much shorter and less aspirational than the previous Trello board. The goal with the new roadmap is to give the community a concrete list of features the core team is definitely working on in the near to medium term future. We think that’s going to be more useful than a list of (great but often large) features that could take multiple years to ship.
The new format was inspired by Docker’s roadmap, thanks Docker!
That’s a roadmap for a $20M-funded company? 
"We hope to change this in the future as we figure out strategies to decentralize Meteor development."
I guess $20m can be burnt through pretty quickly in start up land…
If this is till end 16, the roadmap seems to have gone from ‘overly’ to underly ambitious 
Actually, the $20M was Series B, after $11.2 in Series A, according to Google. But yes, $20M is not much in startup land.
heres the commercials
Apart from the maintenance plan, there’ll be Apollo to add too no doubt. Still, ‘appears’ like momentum being lost a little
Yeah notice that a lot of the stuff you’re used to in Meteor - accounts, data, client-side data, view integrations, etc. is moving into Apollo in the medium term. So it’s still available as part of Meteor, but also will be available to the wider community. A big chunk of the millions is going there.
Folks, keep in mind this Roadmap is for the Meteor project. A large part of the Meteor codebase is the livedata/minimongo/ddp sub-projects. In the future, this will be succeeded by Apollo which is where the majority of our current R&D effort is going. In addition, we now have engineers working on Galaxy who were previously on the Meteor project.
Whilst I realize it must look like we’re divesting from the Meteor project let me assure you this is not the case. Viewed holistically, we believe Meteor+Apollo+Galaxy is the stack of the future. We now have teams within the company working on each of these projects where previously all of the core engineers were assigned to just Meteor so it may have appeared like the project had more momentum.
I think it’s clear the roadmap I posted is too focused on meteor/meteor in the short term and ignores the wider landscape of what we’re working on. I’ll add some more details and post an update on this thread.
Thanks for sharing these smaller byte sized roadmaps. Always nice to know where things are heading.
@zoltan is my new favorite MDG employee.
Thanks for the clarifications.
I’ve been worried that Meteor was starting to reach it’s end-of-life, or at the very least slowing down and loosing track.
I hope it does continue to evolve, and grow, and stabilize, and speed up, and optimize, and push us forward.
I’ll keep evangelizing for Meteor, if you keep making a cutting edge platform that’s simple, fast, and effective.
Looks good. Thanks for the updates.
Question: are there still going to be the concept of release tracks?
If there are two features we could preserve from Atmosphere, my vote would be isomorphic packages and release tracks. I know that very few people have experimented with them outside of MDG, but they really are one of the most underrated and most powerful features of the entire build tool.
Ok, all sounds good BUT…
I’m a professional developer and I need stability e long term vision. When Apollo will be release? As Meteor 1.3 release I will be a lot of migration in best practice that make instability and frustration? How many impact Apollo have to the Meteor platform? thanks
@zeroasterisk - Far from it! We believe the transition to npm and a more open development model will in fact expand Meteor development. We’re working hard on delivering SQL and better data layer performance analysis via Apollo, we should make that more clear in the roadmap.
@arcy - We don’t yet have a release date for Apollo. Rest assured however that as it matures you’ll be able to start using it within existing Meteor apps alongside livedata. We don’t envisage a world (at least not for a long time and without plenty of transition period) where livedata is replaced by Apollo.
That looks good and I’m very excited for Apollo.
However, I’m disappointed Vue.js is not mentioned as one of the officially supported view layers in 1.4. @zoltan, is it possible this will change as popularity increases (it’s already surpassing Angular)?
For now, the core team isn’t working on official support for Vue.js. There is already a good integration package available here.
No firm plans on this yet. What I imagine may happen is that once the npm solution is at feature parity with what we have now and package authors have had a chance to learn the new approach, the day will come where we freeze Atmosphere and new package versions will need to be released on npm.
How will release tracks and future releases of Meteor be handled? Back when it was a git based system, we tracked which npm packages worked together by checking them into the meteor/meteor repository. When Atmosphere came along, we replaced that, and began registering which npm packages work together as release tracks. Even if Atmosphere which is used to serve up packages and build apps gets deprecated, how will release tracks get registered? What will define Meteor 1.5, 1.6, etc?
We’re still figuring this out and plan to do so together with the community. On the one hand the reason we designed the notion of release tracks is to create a stable upgrade path and to ensure core packages work well together. This notion of stability is obviously great and not something we’d like to give up. Having said that, it does make it more difficult to move the project forward faster by releasing individual packages more often outside of the large monolithic release process. It’s also more difficult to co-ordinate releases between MDG and outside package authors. These days, production Meteor apps rely on many more packages than what we provide in core, so the assurance that core packages work well together doesn’t have as much weight as it did in the earlier days.
Well, sure. It’s easy to be on the bleeding edge, and move stuff forward faster by breaking things. It’s more difficult to be stable, reliable, and integrated.
For what it’s worth, the release tracks are something that Atmosphere and MDG got right with the package manager (imho); and will hopefully be on the short-list of things to keep/migrate, along with the isomorphic packages. At the very least, the release tracks are a great enterprise feature for keeping multiple apps and microservices in sync through the development process. I understand that only a small minority of customers are using release tracks. And it can take quite a while to set things up. But like continuous integration servers; once done, they architecture payoff can be substantial. I’m not sure how else one would coordinate a multi-app microservice-based architecture without them.