One of our goals is to be suitable for enterprise and consulting shops, and that means we will need to declare a point after which we will do everything we can to maintain backwards compatibility. That point will be the 1.0 release.
One of our goals is to be suitable for enterprise and consulting shops, and that means we will need to declare a point after which we will do everything we can to maintain backwards compatibility. That point will be the 1.0 release.
Good luck with Meteor. :)
It's a very good idea to limit the number of external packages you depend on in any environment. And if you take the time to inspect the source code behind a package before you commit to using it in your project, you can make things easier for yourself in the future. MDG (Meteor Development Group) is very transparent about what they're changing and why - just follow the meteor-core Google group, and/or watch the commits on their github page. If you're paying attention, you will often have a month or two of warning about what a future release will contain.