So there seems to be folks complaining about how fast this release was and other folks saying it's not a big deal because 4.2.x is LTS. But I don't see anyone addressing the actual issue of breaking changes in node: npm.<p>What does a module author do? If my module uses an API that was changed in 5.x, do I only support 4.2.x, do I only support 5.x or do I write in some hacks to try and check between the two? What if 6.x comes in, say, 6 months and also breaks another API. Now I have 3 hacks or I only support 4.2.x or 6.x.<p>This is the first major version since the io.js and node.js merger so I'm not <i>that</i> concerned yet but if they continue this pace then I will be very concerned (just like I was concerned when npm was supporting io.js and node.js when they had differences in their APIs; it forces module developers to choose and limit their availability). I would like to see some path of deprecation for node.js APIs that take multiple major versions to get away from unless it's a major security risk.<p>Edit: just to clarify my worry: I'm not worried <i>yet</i>. But, and this is a big but, ECMAScript doesn't include any standard libraries for interacting with systems, http, etc so node.js has kinda assumed the role of a standard, defacto library for JavaScript when dealing with a system on a level outside of a web browser. So if the breaking API changes are going to occur every year or faster, to me that's like a language's standard libraries changing every year or sooner.<p>Yes it's kinda not fair as node.js is NOT a set of standard JavaScript libraries but that's the role it's essentially been given due to the lack of one in ECMAScript.
Good lord people...<p>1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+<p>2. 5.0 followed 4.0 so closely because 4.0 was the iojs/node merge and 5.0 was to correspond with the new V8 release, future major bumps will be closer to 6mo (to match V8)
I recently looked at using Node for a simple API backend. ES6 seems like it's not there yet, the stability of Node makes me wary. Constant changes seem exhausting to keep up with. For a simple microservice api you don't want to be upgrading it every 3 days. The continuous change doesn't make sense to me. Trying to get up to speed on all the Node.js ecosystem feels exhausting, only to have it change a few weeks later. Maybe someone using this daily for real APIs could comment if this is the case for them?<p>I ended up opting for Flask and Python 3x instead, couldn't be happier. I had my API up and running within a day with no prior knowledge of Flask and some Python on and off. I've been able to discuss and teach other team members on it who were also able to pick it up easily.
There's a lot of confusion and concern in here about the release of a new major version very soon after the release of another major version (v4.0.0 was released just a month and a half ago). Please note that this is a special release prompted largely by the odd timing of a new release of Google's V8 [1].<p>If you're looking for solid, long term stability, you are perfectly fine sticking with v4.0.0, as its marked an "LTS" release. This means it'll be actively receiving minor- and patch-level updates for 18 months, then for 12 months thereafter it'll get updates for severe bugs and security problems (what they call "maintenance" mode) [2].<p>[1] <a href="https://twitter.com/rvagg/status/659871982670884864" rel="nofollow">https://twitter.com/rvagg/status/659871982670884864</a>
[2] <a href="https://medium.com/@nodesource/essential-steps-long-term-support-for-node-js-8ecf7514dbd#.wutoxcg53" rel="nofollow">https://medium.com/@nodesource/essential-steps-long-term-sup...</a>
I'm not sure why so many people are freaking out.<p>Looking at the changelog, it looks like they decided to commit a bunch of breaking changes that were previously marked as deprecated. If your code was running before without warnings, upgrading shouldn't have a negative impact.<p>The pace of change is fast because node ES6 support is progressing fast enough to maintain near 1:1 feature parity with v8. A bunch of ES6 features still haven't been fully implemented in v8 but that's not the fault of the Node.js dev team.<p>If the dev team has committed to LTS for 4.2 that means they're likely planning to backport new features to the 4x branch. No reason to panic. Many of the more useful features of ES6 already work perfectly in 4.2.
Glad to see they've bumped up the V8 version so the spread operator can be used.<p>Things are really moving along at a good clip since the merge with io.js.
We use node on Windows for our asset minifiers, hopefully the new version of NPM will make this a little more pleasant!<p><i>Your dependencies will now be installed maximally flat. Insofar as is possible, all of your dependencies, and their dependencies, and THEIR dependencies will be installed in your project's node_modules folder with no nesting. You'll only see modules nested underneath one another when two (or more) modules have conflicting dependencies.</i>
And it still uses OpenSSL as a CSPRNG, rather than the operating system's CSPRNG (CryptGenRandom, /dev/urandom, etc.). I guess maybe they'll fix that in 6?
This release timeframe was announced quite a while ago. As others have mentioned the quick jump from 4 to 5 was primarily due to the io.js convergence.<p>Expect future major releases on a 6 month cadence with LTS releases every 12 months<p><a href="https://nodesource.com/blog/essential-steps-long-term-support-for-nodejs#how-long" rel="nofollow">https://nodesource.com/blog/essential-steps-long-term-suppor...</a>
seems to be broken for mac os x, installed from 4.0.0 and seems that npm is broken, running npm install gives me npm ERR! code MODULE_NOT_FOUND.<p>i reverted back to 4.0.0
I found this out last night at 3am after rushing to provision a server. i don't have a great handle on semver or dev cycles, point ceded, but they released 4.2 on october 12th. thats like .1 every 2 days.