"We are proud to announce the release of Node.js v4.2.0 "Argon", the first release covered under the new Long Term Support plan!
As an LTS release, support for v4.x will continue for a period of 30 months from today."
I'm a bit lost here, so 4.2.0 is the _first_ LTS, v4.x will be supported by 30 months, what about 4.0.0 then? isn't 4.0.0 also v4.x? but it's not LTS? Shoud we replace v4.x above with v4.2.x instead?
> Note that while it is possible that critical security and bug fixes may lead to semver-major changes landing within an LTS stream, such situations will be rare and will land as semver-minor bumps
Starting from 4.x, every 2nd major version of Node will be LTS (4.x, 6.x etc). But we should expect a few of the early versions of each of these major versions to not be LTS - hence 4.0.x and 4.1.x didn't count as LTS when they were initially released.
But Node is now using Semantic Versioning [1], which mean that there will not be any breaking changes between each 4.x release. So 4.2.x is backwards compatible with 4.1.x and 4.0.x. And 4.3.x will be backwards compatible to 4.2.x etc.
So in essence the entire 4.x branch will therefore be LTS counting from today. So even if we in 29 months release 4.22.0, this will not extend the 30 months.
What happens 9 months down the line when v8 stable reaches 48.x? I thought that under semver Node would most likely be a semver-major whenever v8 is the same. If my assumption is correct, how will we handle 6.x and 8.x a potential 18 months from now? Will the LTS maintainers have to worry about 3 LTS versions?
I've been following most discussions on Github and TC meetings, but haven't come across this case yet.
> npm: Upgrade to npm 2.14.7 from 2.14.4, see release notes for full details (Kat Marchán) #3299
Is that correct that npm 3.x with the flat node_modules isn't in the first lts tree? We're still very likely to run into path length problems on Windows?
That would be a shame. I know 3.x doesn't fix it but anything to make it less likely is a win. Now we're screwed for nearly 3 years.
I'm not a node or npm apologist but it is seriously time Microsoft update what it considers a reasonable maximum PATH length for Windows to something that makes sense for this era of computing (as well as the tiny ass box you type it into)
We are on a roll with resizable terminals that reflow text in Windows 10 though so I won't push my luck.
It's not really a simple change: this is Microsoft respecting decades of API backward compatibility. New APIs support much higher PATH length, for what it is worth, it's just that a lot of software, for various accumulated reasons, rely on older APIs.
For whatever their other faults, it's hard to blame Microsoft for treating backwards compatibility seriously. It's an amazing thing that in 2015 you can still run VB4-built Win32 application binaries built in 1995. (Not that I recommend people actually do so, given a choice in the matter, of course.)
Agreed. But it still a bit disappointing that they haven't improved the GUI for editing the system path (as observed by the parent comment), but perhaps that also impacts backwards compatibility in some subtle way.
An LTS release is a really nice time to wrap up all these "and then" steps to getting software working. Especially if you want software deployed across an organisation.
>Having just started learning about and using node, I read this release note and then this made me say to myself, "What the fuck?"
If you've started learning node, then it probably makes sense to follow the community portals and news too. In which case you'd known about io.js and the 4.x thing.
In other words, get into the whole project / community / culture.
I think monitoring the repository for an open source project you depend on is critical. Even if you're not trying to be cutting edge, we have several years of security incidents that tell us that you can't turn a blind eye.
On the contrary. It's when you need to use the tools when you most have to get into the community/culture.
If you just wanna learn something as a hobby, have fun, etc, then you don't have to do anything.
But knowing about the product, its community and its release roadmap is essential for anything you want to use to put something in production.
Actually it's essential for even considering to use this technology over another. And I wont even get into security and stability issues that a closer look at the project will make you aware of sooner.
a LOT of stuff have happened in the Node community over a very short period of time. So it's understandable that not everyone have had the resources to follow everything :)
Especially if you're just getting started and not using Node full time yet.
1) At the very least, read the projects About Us/History page, and its Wikipedia article, to get a sense where it stands for in the grand scheme of things.
2) Do some searching to see what alternatives exist. Even typing "alternative to Node.js" will give you some starting points. E.g. when you find out about NW.js and want to use it, it would pay to know that there's also Electron. If you learn there's this hot Angular thing, it should pay to also check React and Ember.
3) Also check how "alive" the project is. Things like GitHub followers, latest commits, release frequency, etc, will give you a sense of that. You don't have to go wild with this and (2) -- just check the 2-3 more prevalent projects in your niche. Again, if you don't what those are, a search like (2) will help. Or ask Quora or even HN.
4) Check the published roadmap.
5) If you want to get even close to the project community, most have an aggregator blog, or an official project blog. E.g. "Planet PHP" etc. There's also frequently mailing lists with links (e.g. Javascript Weekly). You can start reading whatever posts seem interesting to you -- soon you'll have a sense of what the key players are, what developments are coming, etc.
6) Check the relevant Reddit channel for the framework/project/language, or HN for stories on it.
The first 4 items don't take more than half a day to go through (of course you could spread them in a weekend or a whole week).
The (5) and (6) are more advanced, but still you can dip your toes slowly into them too -- a couple hours per week or so.
For more advanced involvement, you can go on irc and say hi to some devs and helpful volunteers. At later stages you can join their dev mailing lists, and even volunteer and help the project yourself.
long story short? There was a fork (called iojs) that moved to using semver and it used v1.0-3.0. It was then merged back into Node (with a ton of great changes to the leadership and development of Node) and the extra changes bumped it to 4.0.
But yeah, it's semver so it's more "we've had 3 cycles of major breaking changes" than "it's a completely new product".
As others have pointed out, a lot of stuff have happened over a very short period of time. Among the things, Node have a switch to use Semantic Versioning (semver) where the leading version number (major) is bumped every time a breaking change is introduced. The result is that the major version will increase more quickly than we've been used to. If you'd like to read more about semver, check out: http://semver.org
Not sure why you're being downvoted. As others have said, there have been very rapid, recent developments in the node.js world. I think the question is valid, especially for a beginner.
That version is from April 2014, and was a full production version behind even before the merger. ("major" releases were even numbered - 0.8, 0.10, 0.12, etc) The current 0.10.x is 0.10.40, which means you were missing out on performance/security fixes.
Depends on what you're running in production. As an admin, I'd say stick with the LTS releases. If you're not in production, or you can bundle your Node with your app (like in a container) then I'd vote for "go wild".
46 comments
[ 4.6 ms ] story [ 168 ms ] threadAs an LTS release, support for v4.x will continue for a period of 30 months from today."
I'm a bit lost here, so 4.2.0 is the _first_ LTS, v4.x will be supported by 30 months, what about 4.0.0 then? isn't 4.0.0 also v4.x? but it's not LTS? Shoud we replace v4.x above with v4.2.x instead?
https://github.com/nodejs/LTS/
Specifically:
> Note that while it is possible that critical security and bug fixes may lead to semver-major changes landing within an LTS stream, such situations will be rare and will land as semver-minor bumps
Starting from 4.x, every 2nd major version of Node will be LTS (4.x, 6.x etc). But we should expect a few of the early versions of each of these major versions to not be LTS - hence 4.0.x and 4.1.x didn't count as LTS when they were initially released.
But Node is now using Semantic Versioning [1], which mean that there will not be any breaking changes between each 4.x release. So 4.2.x is backwards compatible with 4.1.x and 4.0.x. And 4.3.x will be backwards compatible to 4.2.x etc.
So in essence the entire 4.x branch will therefore be LTS counting from today. So even if we in 29 months release 4.22.0, this will not extend the 30 months.
[1] http://semver.org
I've been following most discussions on Github and TC meetings, but haven't come across this case yet.
> As an LTS release, support for v4.x will continue for a period of 30 months from today.
They will likely semver major node into 5/6 etc, but that doesn't change the fact that 4.x will continue with 2 and a half years of LTS.
Not sure if that completely answers your question, and I could be wrong.
Is that correct that npm 3.x with the flat node_modules isn't in the first lts tree? We're still very likely to run into path length problems on Windows?
That would be a shame. I know 3.x doesn't fix it but anything to make it less likely is a win. Now we're screwed for nearly 3 years.
We are on a roll with resizable terminals that reflow text in Windows 10 though so I won't push my luck.
For whatever their other faults, it's hard to blame Microsoft for treating backwards compatibility seriously. It's an amazing thing that in 2015 you can still run VB4-built Win32 application binaries built in 1995. (Not that I recommend people actually do so, given a choice in the matter, of course.)
http://www.ghacks.net/2015/09/22/microsoft-improves-environm...
Here is a stop-gap:
https://www.npmjs.com/package/flatten-packages
[15:39 user@host ~] > node -v
v0.10.25
[1] https://github.com/hokaccha/nodebrew
[1] https://github.com/tj/n [2] https://github.com/creationix/nvm
If you've started learning node, then it probably makes sense to follow the community portals and news too. In which case you'd known about io.js and the 4.x thing.
In other words, get into the whole project / community / culture.
If you just wanna learn something as a hobby, have fun, etc, then you don't have to do anything.
But knowing about the product, its community and its release roadmap is essential for anything you want to use to put something in production.
Actually it's essential for even considering to use this technology over another. And I wont even get into security and stability issues that a closer look at the project will make you aware of sooner.
Especially if you're just getting started and not using Node full time yet.
Could you elaborate on that? Which resources do you think would be useful to be followed to get into the culture and community?
2) Do some searching to see what alternatives exist. Even typing "alternative to Node.js" will give you some starting points. E.g. when you find out about NW.js and want to use it, it would pay to know that there's also Electron. If you learn there's this hot Angular thing, it should pay to also check React and Ember.
3) Also check how "alive" the project is. Things like GitHub followers, latest commits, release frequency, etc, will give you a sense of that. You don't have to go wild with this and (2) -- just check the 2-3 more prevalent projects in your niche. Again, if you don't what those are, a search like (2) will help. Or ask Quora or even HN.
4) Check the published roadmap.
5) If you want to get even close to the project community, most have an aggregator blog, or an official project blog. E.g. "Planet PHP" etc. There's also frequently mailing lists with links (e.g. Javascript Weekly). You can start reading whatever posts seem interesting to you -- soon you'll have a sense of what the key players are, what developments are coming, etc.
6) Check the relevant Reddit channel for the framework/project/language, or HN for stories on it.
The first 4 items don't take more than half a day to go through (of course you could spread them in a weekend or a whole week).
The (5) and (6) are more advanced, but still you can dip your toes slowly into them too -- a couple hours per week or so.
For more advanced involvement, you can go on irc and say hi to some devs and helpful volunteers. At later stages you can join their dev mailing lists, and even volunteer and help the project yourself.
But yeah, it's semver so it's more "we've had 3 cycles of major breaking changes" than "it's a completely new product".
https://nodejs.org/en/download/releases/
Also, it's not unusual for project to totally jump versions - a notable example is Rake, which jumped from 0.9 to 10.0.
1. On your dev machine, if you are using 4.x, should you keep updating to the newest 4.x version or stay with this version?
2. If you keep updating and use a version manager like nvm, is there an easy way to install global packages(like gulp, grunt, etc) for new versions?
Gonna play hell with seo for my open source projects:
https://github.com/geuis/argon
https://github.com/geuis/helium-css
https://en.wikipedia.org/wiki/List_of_elements