Long Term Support for Meteor API's

[msavin]

Back when the infamous Blaze thread was announced, I noticed the vibe in the community changed, completely. Given how unpredictable and unplanned it was, people had difficulty trusting the platform.

The people that I've kept contact with all began to slowly diversify and ultimately abandoned the eco-system. Perhaps the biggest indicator of "lack of faith" I've noticed had been in Meteor Toys sales - that thread really hurt sales.

Apollo multiplied that effect even further.

However, many of us are still enjoying Meteor, its a good product and the alternatives may not be so attractive. It also looks like Meteor may be expanding to new audiences. Plus, Ben had been doing a lot to ensure Meteor is up to par with the competition.

One of the things that made people confident in IBM, Microsoft, Node, and even some Meteor packages, is long term support, and it would be great to see Meteor restore confidence in its community through similar means.

[hwillson]

Hi @msavin - could you elaborate further on what you think Meteor should be doing to improve its long term support? I've found the platform itself be incredibly backwards compatible, and have had no problems continuing to use older versions for years. Upgrading old apps to use new Meteor versions has been amazingly pain free, which definitely shows the projects commitment to supporting its user base, no matter which version of Meteor they're using. Are there any specific areas Meteor should improve on, or is there a more detailed (and documented) long term support process you think Meteor should have in place? Any ideas you have about building this out further would be greatly appreciated.

[msavin]

@hwillson thanks for your note

There is a conversation going on about it here: https://forums.meteor.com/t/meteor-needs-long-term-support/37262

The idea behind LTS is that the Meteor APIs would be guaranteed to be stable/supported until a certain date. That way, someone can build a solution and know that it will last for some time.

It prevents the risk of something like this: Step 1: Meteor announced deprecation of Feature X Step 2: Feature X has bugs, and breaks when running a new version of Meteor Step 3: Someone gets fired or goes out of business

Meteor has been incredibly reliable in this department, and in some ways, by not offering LTS they are under-marketing the effort. On the other side of it, many businesses will evaluate LTS before adopting a technology, so it can drive adoption and bring in great customers for Galaxy.

[hwillson]

Thanks - I've been following the forum discussion, but I haven't really seen anything concrete yet that we can start planning around. People like the idea of LTS, but I think we need to nail down exactly what needs to be implemented. As you mentioned, Meteor has already been incredibly reliable in the area of making sure its public API's stay stable/supported for a long period of time. I think you're right about the under-marketing in this area - maybe this just needs to be advertised/promoted more thoroughly? Would putting together a small LTS plan and schedule (stored in the main GH repo) be a good first start (something like Node's LTS plan)?

[StorytellerCZ]

My thoughts:

Something like the Node LTS plan would be great. I think that the selling point of LTS would be that it would be getting backward fixes and security updates while that might not happen to normal release once a new 1.x release is made. So say 1.6 gets designated as LTS. It would then get patched up for the duration of LTS, while 1.7 would stop getting patches once 1.8 is out and so on.

[msavin]

I think that makes sense when you have a product that is always changing heavily.

With Meteor, I think just having LTS on the APIs would suffice. In the most basic sense:

• if I write a method or subscription, can I be assured it'll run across all versions?
• if I use minimomgo on my client, can I be assured it won't get broken and deprecated in 6 months?

I should add that currently, it's been the case. But we never know where things are going.

On Monday, June 19, 2017, Jan Dvorak notifications@github.com wrote:

My thoughts:

Something like the Node LTS plan would be great. I think that the selling point of LTS would be that it would be getting backward fixes and security updates while that might not happen to normal release once a new 1.x release is made. So say 1.6 gets designated as LTS. It would then get patched up for the duration of LTS, while 1.7 would stop getting patches once 1.8 is out and so on.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/meteor/meteor-feature-requests/issues/110#issuecomment-309484357, or mute the thread https://github.com/notifications/unsubscribe-auth/AB7-g_cujNHW25z1n5__wSEYcpsIaZ5Qks5sFpo9gaJpZM4N6CEe .

[smeijer]

With Meteor, I think just having LTS on the APIs would suffice.

That sounds a bit like "All official packages can get a LTS stamp". Because all official packages that I'm using, are there from the beginning. I even still have a couple of Blaze components that still do their job just fine. Even though I've started migrating from Blaze to React a long time ago.

The only thing that frustrated me about LTS was the panic around disposing Blaze. That cost me a lot of work, because I too panicked and started migrating to React a little to fast. I'm happy with React though, so no hard feelings a.t.m.. Just trying to say that LTS is more in the communication and that kind of panic-posts. But I feel like MGD already learned that lesson, and we're past that subject.

So say 1.6 gets designated as LTS. It would then get patched up for the duration of LTS, while 1.7 would stop getting patches once 1.8 is out and so on.

Yes, that would be an option. But Meteor is doing even better than that. All versions gets lot of updates, and I haven't noticed any breaking changes in official packages so far.

I think the biggest challenge lies in maintaining external dependencies. Like the dependency on underscore or jQuery. I've just finished a big migration because lodash changed their api quite a bit. I know lodash isn't used in Meteor, but the same can happen with other third party libs.

What also can happen in the LTS feeling, is to publish some dependency graph. So we can see what third party libraries are being used and why they are there. Think of the bundle-visualizer, but on docs.meteor.com in a normal flowchart way that could be used in presentations / documentation.

[msavin]

https://forums.meteor.com/t/meteor-needs-long-term-support/37262/29?u=msavin

I just checked out the Google Trends on Meteor, and see for yourselves: the trend drops on November 2015, the same time as the infamous Blaze thread, and it never recovers.

[smeijer]

Yeah, you can feel it in the community as well. I didn't want to start another "Meteor is dead" topic; but I've browsed https://forums.meteor.com lately, and there is so much less activity there.

My own topic for example: What component explorer / component dev tool do you use? Can be a quite interesting topic / discussion, but after a month it hasn't received even a single reply.

"In the old days", there was a lot of activity on the forums. If you check the frontpage now, it's quite sad:

forums.meteor.com

| Topic | Category | Replies | Views | Activity | |------------------------------------------------------------------|----------|---------|-------|----------| | Meteor Needs Long Term Support | | 28 | 1.8k | 24m | | Sheet.js XLSX to be used in client side in meteor | | 5 | 55 | 40m | | Using User custom fields rather than Roles packages? | help | 1 | 34 | 2h | | Templates don’t work as expected | help | 1 | 45 | 9h | | Hierarchy / Tree: removing a node with all descendants | help | 5 | 56 | 10h | | Issues with using publications with view instead of a collection | help | 5 | 56 | 13h | | Private Source Maps with Monti APM | announce | 0 | 43 | 13h | | Testing Meteor apps in 2018, a rant 9 | testing | 39 | 1.9k | 14h | | ... * cut * ... | | | | | | Howto delete image from Cloudinary? | help | 3 | 61 | 1d | | Migrations and health check timeouts | deployment | 1 | 47 | 1d | | loginExpirationInDays - set per user | help | 0 | 34 | 1d | | Add license validation to a Angular library | angular | 0 | 31 | 1d | | Update Angular Todo App tutorial to use Components | meta | 0 | 45 | 1d | | Weird issue where package isn’t found in Atmosphere search | help | 0 | 38 | 1d |

.

I don't want to hijack this issue to much, but I'm not sure if LTS will bring Meteor back to life. Like I said before. Regarding to LTS, meteor is doing a great job by being backwards compatible.

I think MDG should re-evaluate "what" meteor is. Currently, it also doesn't get the priority it deserves, as @benjamn seems to be the only one working on it (deserves to say he is doing a great job!)

pulse


.

Also; comparing the commits of this year to the same period last year. You'll see that there was double the activity a year ago: (551 commits so far in 2018, 1270 commits in same period in 2017, (based on top 4 contributors) )

contributers 2017-01-01 - 2017-10-05 vs 2018-01-01 - 2018-10-05


.

Doc's aren't updated any more. .meteorignore is still not documented. And release v1.7.0.4 and v1.7.0.5 are not on the changelog, despite being adversised by the meteor tool.

• buildtimes are slow
• switching branches suck https://github.com/meteor/meteor/pull/8165
• less activity on the repo
• no clear path / roadmap
• only a single MDG contributor

I've got exicted by this post: https://github.com/meteor/meteor/pull/9942#issuecomment-426817206 where Ben writes that 1.8 will be released soon. On the other hand, reading something like we hear you without any serious follow up, doesn't revive my trust in the future of Meteor.

In terms of communication, it would be nice if we could get a visual roadmap of where MDG thinks Meteor is heading. Also; it would be nice if there would have been a blog post on the moment that @stubailo left the team. I know, that's not required, but it would have been nice to inform the community.

Sorry for the rant and hijack, I just don't believe LTS would bring back Meteor. I think Meteor stands for LTS. But what's worth LTS, if there is only a single contributer and no clear roadmap?

In the mean time; I'm still using Meteor for a SaaS, but I definitly, slowly, keep migrating away. Untill it's just the build tool that I can replace.

[msavin]

@smeijer

Sorry for the rant and hijack, I just don't believe LTS would bring back Meteor. I think Meteor stands for LTS. But what's worth LTS, if there is only a single contributer and no clear roadmap?

This is the exact point of LTS. It means that things will continue to be maintained, and if that single contributor steps down, that MDG would find someone to take his place.

Right now - MDG has been giving Meteor the LTS status but not the commitement. It's kind of like saying, "why get married if we're in a relationship?"

[jamesgibson14]

I just updated 2 old production Meteor with Blaze apps to 1.7 and they both almost went flawlessly, in 9 years of Javascript programming I have never updated a major library or framework with such ease.
I can scale them easily with Redis-oplog and cheaply with some of the amazing tools Digital Ocean is putting out. We also have Apollo and Vue integrated with Meteor and it is running great. I have used Next.js, Nuxt.js, Node + Hapi, Node + express, and I still think Meteor is better by far, even with Blaze instead of Vue. And although I do like Apollo + graphql, I think DDP/methods with reactivity is better. We have both 1.7 and 1.8 this year with amazing new features. I agree we lost some of the community but those of us still using Meteor are doing Awesome things!