Meteor 3.0 migration considerations
opened this issue · comments
In preparation for the porting of the package to version 3.0, I would like to share how we should behave. To understand the context, I have prepared a simple table with the availability of mongo methods in the various versions:
| Mongo methods | pre 2.12 | 2.12/2.13 | 3.0 |
|---|---|---|---|
| Async server-side | NA | X* | X |
| No Async server-side | X | X | NA |
| Async client-side | NA | X* | X |
| No Async client-side | X | X | X |
- NA=Not available
- * With a mutation that use a Promise.resolve.
My question is as follows: is it worth supporting all cases both client-side and server-side, or is it better to focus on the asynchronous variant alone? Writing all tests for all combinations, even the deprecated ones, may not make sense. What do you think?
Thank you for submitting this issue!
We, the Members of Meteor Community Packages take every issue seriously.
Our goal is to provide long-term lifecycles for packages and keep up
with the newest changes in Meteor and the overall NodeJs/JavaScript ecosystem.
However, we contribute to these packages mostly in our free time.
Therefore, we can't guarantee you issues to be solved within certain time.
If you think this issue is trivial to solve, don't hesitate to submit
a pull request, too! We will accompany you in the process with reviews and hints
on how to get development set up.
Please also consider sponsoring the maintainers of the package.
If you don't know who is currently maintaining this package, just leave a comment
and we'll let you know.