If you’ve been trying to follow the recent history of Meteor releases since 1.3.3 was announced ten days ago, chances are you have some questions:
- Why did we release 188.8.131.52?
- Why did we then release 1.3.4 instead of 184.108.40.206?
- What is the current recommended release?
- When can I start using Meteor 1.4?
I will answer these questions below. If you have other questions, just ask!
Why did we release 220.127.116.11?
Meteor 18.104.22.168 was an immediate follow-up to 1.3.3, aimed at fixing bugs encountered predominately by Windows developers. Here is the complete list of changes.
The worst of the problems stemmed from the arbitrary 260-character limit imposed by Windows
cmd.exe and PowerShell on the maximum length of file system paths. Because
npm is all too happy to nest
node_modules directories to unlimited depths, it’s only a matter of time before a large
npm-based application hits these limits. Windows developers have noted this frustration before, and it seems Microsoft has no plans to address it.
The path length limit may be frustrating, but one can usually hoist
npm packages higher in the dependency tree to work around the nesting limitations, and that’s exactly what Meteor 22.214.171.124 did for the
npm dependencies of the
babel-compiler Meteor package.
Why did we then release 1.3.4 instead of 126.96.36.199?
node_modules directories seemed like an appropriate stop-gap fix for a 188.8.131.52 follow-up release, the underlying problem calls for a more general solution.
In particular, if Meteor had been using
npm@3 instead of
email@example.com, then all of its
node_modules directories would be automatically flattened as much as possible, which is good news for all Meteor developers, but great news for Windows developers.
That said, upgrading the major version of
npm used by Meteor is not a trivial change! I wanted to do it eight months ago, but we settled on shipping
npm@2 with Meteor 1.3. Given the
npm-related bugs in Metor 1.3.3, and our misgivings about the longevity of the solution provided by 184.108.40.206, we decided it was finally worth the effort and risk to switch to
Now, because Meteor uses
npm-shrinkwrap.json files for package
npm dependencies, the structure of
node_modules directories for Meteor packages should not change until those packages are republished, and the shrinkwrap files are rewritten. And because Meteor does not run
npm install on your behalf for application
node_modules, it’s up to you to decide when you want to reinstall your
node_modules using Meteor 1.3.4 and
firstname.lastname@example.org. For these reasons, we do not anticipate any unwelcome breaks in backwards compatibility due to the
npm upgrade, though it certainly seemed to warrant a 1.3.4 release, rather than a 220.127.116.11 release.
Since we were cutting yet another release, we took the opportunity to implement some significant IO performance improvements as well. Here is the complete list of changes in Meteor 1.3.4.
What is the current recommended release?
I would like to say that Meteor 1.3.4 was the final answer to everyone’s problems, but unfortunately forward progress always has risks. This seemingly innocent pull request included in Meteor 1.3.4 added a timeout to HTTP requests made by the
meteor command-line tool, which broke
meteor deploy for Galaxy developers whose uploads took longer than 30 seconds.
That problem was fixed in Meteor 18.104.22.168, and so now 22.214.171.124 is the version of Meteor that you’ll get when you
When can I start using Meteor 1.4?
If you’re ready to start using Node 4.4.5 and Mongo 3.2, I’m happy to announce the latest beta release, which you can install by typing this command:
meteor update --release 1.4-beta.7
You can follow the developments (and report any problems) here.
Thanks for bearing with us!