Thanks for asking. I think it doesn’t because it’s optional – I need npm for React and supporting Meteor integration.
From what I understand, Apollo will be something that’s included, and will add to and modify existing infrastructure, when I do a $ meteor update --release@1.5
It won’t be. So that’s good to clear up!
Oh, wow, this is probably not the right spot, but I’d really like to know now how Apollo will be “integrated” with Meteor. Will it be as simple as a npm install? And will 1.5 then just be Meteor classic with “hooks” of some sort for Apollo?
If this is the case, the implication is from that point you just work on the Apollo as a npm package, with its own independent releases, and Meteor classic becomes a “integration point” for which one can choose to add Apollo and supporting MDG-based npm packages to or not.
@ramez Ultimately I agree with @sashko that it would be best to direct your efforts towards maintaining components/packages within the existing Meteor org. You’ll get more support from us there and have an easier time attracting other community members to help with maintenance because of pure visibility. I think it’s better for the community to have community-driven components easily discoverable within the Meteor org so that we don’t end up with a very fragmented maintenance effort for the pieces of Meteor classic you really care about.
We’ve put a lot of work into making community contributions possible despite some gnarly technical hurdles, but it seems like there still needs to be a clearer process for community members to step in and get involved and/or to let us know what’s getting in their way of doing so. If you’re interested in hashing this out with me and @zoltan, who’s also been working on the contribution process (as documented here) we’d love to get your feedback.
Thanks @thea, really appreciate you reaching out. Absolutely! Want me to PM you on the forum to choose a time for a call with you and @zoltan?
You’ve got it 100% correct!
Bigger discussion here if you want to join in and talk more in depth: Apollo + Meteor: which features exactly are coming in 1.5?
Ah, did that finally ship? Mozel tov! If so, that may make 1.4.1 a bellweather release, similar to 0.6.5.
Heh. Given my experiences trying to contribute in the past to Meteor and Velocity, I think I’ll stick to something a bit smaller than Accounts to begin with. Maybe a PR to Session or Random to see if things have actually changed.
But maybe. I’d rather coordinate with the useraccounts folks than have it just be on my plate (especially since I have grad school starting in a few weeks).
The clinical:active-entry package we’ve been maintaining has additional requirements like 30 minute timeouts and LDAP authentication - features intended for a corporate/clinical environment. And the work we’ve been doing isn’t really aimed at supporting any/all view layers; just Blaze and React. But we were talking about migrating to use useraccounts:core, and if it would mean being able to integrate auth0:lock and LDAP and an OAuth server into an official solution… well, maybe. That would be worth talking about.
This is a great discussion! I just wanted to add some of my thoughts. We absolutely welcome forks and custom release tracks. This is one of the things that makes open source great!
As core maintainers, we have to ensure a very high bar of quality for contributions we accept into core as they will impact everyone in the community. I know this can be frustrating because it puts a lot of emphasis on having long discussions about design, making sure good tests are included and contributions are aligned around the needs of the majority of our users. I think this can give some users an us vs them feeling, like the folks inside the walls of MDG are trying to maintain dictatorial control over the project. This couldn’t be further from the truth!!
We’re actively looking for more external core contributors who share the project’s values around building solid stable software for the majority. You may have noticed @abernix’s heavy participation on the project in recent times. He does not work at MDG.
The other angle here is technical. The current architecture leans towards a central point of control. The release process can only be executed in house and there is package infrastructure that is designed to be maintained in-house. We’re doing our best to refactor the project towards a more open model (e.g moving towards npm and a light release process) to make it easier for the community to maintain and fork. Due to the complexity of the codebase, this is going to take some time so please bear with us (or help out if you love solving difficult problems!).
I also want to re-emphasize that other than transitioning from Node 0.12 to Node 4, we don’t intend to swap out any of the core components of Meteor in 1.5, 1.6, or any other version. The stuff we add is just that: additions that you can safely ignore.
In fact, probably a lot of the fatigue of people who feel like the official materials like the Guide have switched to a more complicated, module-first, choose-your-own-adventure format could probably be helped by collaborating on a new educational resource that describes the “classic” way of doing stuff, with only Blaze, “global” variables, limited NPM use, etc.
This is a relief to hear!
Thank you for brining this up! Will you be opening a clear channel for contributions and clear place to park this within the exiting resources?
Open to ideas! Where would you park it?
Could be a good idea - we could make another copy of the guide/docs themed app, set up CI, and put it on another URL, like classic.meteor.com or something.
I was hoping these anti-MDG posts died with this post
I think people forget that MDGs business can’t be only the data layer, they also need to provide something special for it, f.e. a fullstack framework which integrates Apollo with ease - and yeah, that will be the “new” Meteor.
I didn’t read it as such. Was suprised to read a lot of positive vibes in this thread. Seemed to be inspiring everybody 
Go team
Let’s make meteor the best it can be, and we’ll figure out how to pay the bills.
It’s called Discover Meteor 
But seriously, I feel like this “Meteor Classic” approach is the wrong solution. I’d much rather have the community focus on making the “new” Meteor simpler and easier to use than divide it between people who want simplicity, and people who want cutting-edge-ness (or whatever you might call it). What if you want both?
I feel like Webpack provides a good case study: for months all I heard about Webpack is how hard it is to set up and configure, yet @benoitt was able to create a no-config, drop-in “Meteoric” Webpack package. Personally I think this is the right path for Meteor: move towards the rest of the JS ecosystem while preserving ease of use as much as possible.
Well, my posting above wasn’t against Meteor. I just think that “Meteor 2.0” will be the framework for Apollo, so it’s only changing but not dying.
Oh sure - I’m just saying a big part of the Apollo strategy is monetizing the data layer directly, in addition to Galaxy for the full-stack platform angle.