Currently, we are actively working on the following tasks:
Fix problems with our tutorials when doing them with Meteor 3 - we’re extensively testing our Alpha version right now to make sure we can refine it more before a Beta version. We already found simple bugs, like Cursor.count() not working properly. So we want to tackle those types of bugs first before releasing a Beta.
Hi everyone! First of all, I want to say thanks for the effort updating Meteor to V3 which is a huge change and we really appreciate.
Currently we’re using Meteor v2.13.3, and lot’s of libraries are forcing us to update to node >= 16 at least, and I’m really worry about this, because our apps are getting outdated since we can’t safely upgrade our libraries. And I think that use meteor 3.0-alpha.17 on production is discouraged since it’s just an alpha version.
I can’t see any deadline for a stable Meteor v3 release. Do you have any deadline on mind?
Do you have any suggestion for people that want to use a more recent Node version and minimize the errors on production?
While that’s something only the core team can give you a definitive answer. You can follow the progress of 3.0 migration by following this thread and the official project board on GH.
Also, since you’re on 2.13.3 you should not wait for 3.0 to be officially released to start working you can already start migrating your applications today as the alpha is already out and provide feedback for the core team.
I was already checking it since a few months, but it doesn’t help me to estimate if it will take 4 months, 6 months or even more to have a stable production version, and all other libraries are pushing us to upgrade in the meantime since we’re running on outdated versions.
you should not wait for 3.0 to be officially released to start working you can already start migrating your applications today as the alpha is already
I know that I should not wait for 3.0 to be officially released to start working on the migration of our applications, but we can’t launch an alpha version into production.
Anyway, sorry if it sounds rude at some point, I really appreciate the whole work that team is doing.
This comment has two main ideas:
Let the community know that we’re also worry about this, because it’s something critical stay using an unmaintained Node version on production.
See if somebody has a good recommendation or workaround for us.
What @harry97 is speaking here about is migrating to the new *Async function calls. You can push those already into production with your existing 2.x Meteor app. They are there for forward compatibility. This way you can migrate your app’s methods step by step and then when the time comes for 3.0 upgrade you will have only minimum work on the remaining API changes.
Let me see if I understood correctly. So what you say is that is safe release our app without any change with meteor 3.0-alpha.17, since it’s retro compatible, and therefore we will be able to use a more recent Node version on Meteor without breaking anything.
No. Implementing the new Async calls will not make it possible to run on newer Node versions right now. Newer Node versions require Meteor to not use Fibers anymore and this is done in Meteor 3. What those Async call allow you to do is to execute some of the migration work right now while you are on Meteor 2.13, so that when a stable version of Meteor 3 ships you’ll have less work to do. At least that seems to be the plan.
This isn’t easy. In one project, we have around 20 npm packages that cannot be updated because of node 14. For a few packages with severe security issues, we were able to find alternatives. But tracking becomes a lot more difficult when the dependencies of those packages are the ones with security updates.
Thanks for the clarification @vooteles. But as @rjdavid mentioned the major issue here are the rest of packages that can’t be safety updated due to this limitation. We’re not worry about doing the app migration from Meteor 2.13.x to 3. We’re worry about still using an unmaintained Node JS version on production and the consequences of it.
Thanks everyone, I just wanted to be sure that our concerns were understood and that there was not any workaround for now.
Hi @charlytalavera, we don’t have an exact ETA for this, but we do have a plan, and the plan is to have this official release in the first quarter of 2024. Things can go wrong, but we’re confident that will be possible. Also, the first beta should be coming at the beginning of December.
As for your question about using Alpha in production, we do not recommend that yet, but you can certainly follow the recommendations everyone gave you above and start migrating your app to use the new async methods. This will save you time in the future.