Migrating packages to *Async and away from Fibers #68
Replies: 4 comments 10 replies
-
I think I will be able to help for some of the packages. We can starts with collection2 |
Beta Was this translation helpful? Give feedback.
-
Please do so, we need every with MCP. It's too much for @storyteller to
handle right now.
…On Fri, 21 Oct 2022, 4:05 pm G, ***@***.***> wrote:
I think I will be able to help for some of the packages. We can starts
with collection2
—
Reply to this email directly, view it on GitHub
<#68 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABSWGQPUFHKI6QMRVL6GXVLWEKPKNANCNFSM6AAAAAARJOBHHQ>
.
You are receiving this because you are subscribed to this thread.Message
ID:
<Meteor-Community-Packages/organization/repo-discussions/68/comments/3934047
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
Here are some packages I use that need rewriting and where it’s unclear if there are any active maintainers. I have created issues for migration to see if there is any response: littledata:synced-cron - percolatestudio/meteor-synced-cron#147 xolvio:cleaner - xolvio/cleaner#26 percolate:migrations - percolatestudio/meteor-migrations#84 If there is no response I can help moving them to meteor-community and try to fix them |
Beta Was this translation helpful? Give feedback.
-
alanning:roles |
Beta Was this translation helpful? Give feedback.
-
With Meteor 2.8 released the time has come to start migrating MCP packages away from the Fibers land as well. As such I would like to discuss which packages to do first and also document here what the progress should be. Since good patterns will emerge over time I would like to start with the smaller packages first.
Status board
https://github.com/orgs/Meteor-Community-Packages/projects/8/views/1
Versioning pattern
If only internal APIs change there should be a feature version bump with
api.versionsFrom(['2.8'])
be set. If publicly consumable APIs change then I think we should just do a major version bump.The README should then include a description which versions are compatible with what versions of Meteor and CHANGELOG should also be very explicit about those things.
Some packages will depend on Meteor API changes that will come in later version ie. Accounts in Meteor 2.9. When that time comes the relevant code should be migrated.
*Async
Until Meteor 3.0 there should be option to use both synchronous and *Async versions of calls. This in order to give a chance for people to migrate. Where possible *Async function calls should be provided alongside the existing API. Where possible internally switch should be made to use the new *Async API.
Packages list
Collection2 - 2.8
I think we can start working on this with release 2.8
Roles - 2.8
linked-accounts - 2.9
Accounts are scheduled for 2.9 so we have to wait will 2.9 release before releasing this, that said hopefully this shouldn't be too much work.
** TODO **
Beta Was this translation helpful? Give feedback.
All reactions