The Meteor 1.4 release is coming up! Below we’ve outlined the main contents of the release, which includes some frequently requested features from our roadmap. We expect that updating will be seamless and require no code changes on your part.
Read on for a preview of the updates we have planned.
Node 4
We’ll be updating Node from version 0.10.43 to version 4 and refactoring the tool to ensure that future Node updates are easy. This means we need to re-think the way binary Atmosphere package dependencies work. Currently, package authors use our build machines to build a version of their package for each architecture that Meteor supports. The resulting binary code has a runtime dependency on the Node version. What this means is that packages currently on Atmosphere that contain binary components would no longer work if we simply shipped a new version of Node with Meteor.
To solve this problem for Node 4 and any future Node updates, we’re going to require Meteor users who rely on packages with binary dependencies to install a compiler toolchain on their development and build machines. We’ll make sure this is a straightforward and well documented process. In addition, we’ll ship Meteor’s core dependencies with pre-built binaries. This will mean that new and simple app development will continue to work without requiring a compiler toolchain.
The good news is that after we make the update to Node 4, updating to Node 6 will be a simple change that we can push out with a small point release when we believe it’s reached an acceptable level of maturity.
Mongo 3.2
We’ll be shipping Mongo 3.2 in the dev bundle along with an updated version of the driver that’s fully compatible with it. The only breaking change may be to require users in development to reset their local databases when updating to 1.4.
Relaxing core package versions
Meteor 1.4 will enable developers to use updated versions of core packages without having to wait for a new Meteor release. Currently, every release of Meteor forces exact versions of core packages to be installed within your app. For instance, Meteor 1.3.2.4 pins blaze at version 2.1.7 . This makes it impossible to use a new version of blaze without publishing a new release of Meteor. There are two important reasons to relax this requirement:
To enable core packages to be released on a separate release schedule to Meteor itself, sometimes by external contributors.
To align Meteor’s approach with that of npm. This is one small step towards transitioning Meteor’s packages over to npm.
You probably won’t even notice this change unless you look in .meteor/packages and find ranges specified against core packages that currently have no version listed.
Stay tuned for more updates
Naturally, we’ll continue working on smaller fixes, features and merging community contributed PRs. I’ll post with more details as they unfold, including a target beta and release date.
Looking forward to a solid maintenance release and the option of using Mongo’s data-at-rest encryption (requires enterprise license; but still). Looking forward to this!
Can’t you also use the Atmosphere build server to automatically build binaries for versions of Node officially supported by Meteor? That would save time and sweat for those using packages depending on binaries.
So, moderately useless, then. I’m liking Mongodb less and less. There’s a reason why you try to normalize stuff in a database - yes, I can denormalize the data and put it into every document it’s relevant to.
And then I update the data - and now I have to do multiple updates instead of just one (and god help me if I forget one). I’m really not seeing the usefulness of these kind of dbs unless you have a singular table with next to no external dependencies.
