Node v4.2.0 (Stable)(nodejs.org)
nodejs.org
Node v4.2.0 (Stable)
https://nodejs.org/en/blog/release/v4.2.0/
11 comments
As far as I remember this is how it works:
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
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
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.
I've been following most discussions on Github and TC meetings, but haven't come across this case yet.
From article,
> 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.
> 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.
I'm pretty sure they do mean 4.2.x will be supported for 30 months... wouldn't expect to see updates to 4.0.x or 4.1.x in that vein.
Here is more information:
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
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
[deleted]
This is great news. A year ago we didn't know if Node would ever hit a 1.0 and now we have an LTS release. Congrats and thanks to everyone involved.
Good to see the pace of Node development since the merger with io.js. Awesome job, Node team!
Questions:
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?
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?
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".
For #2:-
nvm copy-packages v(the version that you want to copy from) should do it.
Having just started learning about and using node, I read this release note and then this made me say to myself, "What the fuck?"
[15:39 user@host ~] > node -v
v0.10.25
[15:39 user@host ~] > node -v
v0.10.25
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.
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.
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.
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.
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".
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".
>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.
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.
Not everyone has time to get into an entire community / culture when they just need to use tools.
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.
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.
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.
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.
Especially if you're just getting started and not using Node full time yet.
> In other words, get into the whole project / community / culture.
Could you elaborate on that? Which resources do you think would be useful to be followed to get into the culture and community?
Could you elaborate on that? Which resources do you think would be useful to be followed to get into the culture and community?
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.
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.
Using your distributions package manager you'll get the older versions. I'm guessing you're using Ubuntu? Better off just compiling from source.
You can also use nodebrew[1], which also allows you to install multiple versions in parallel.
[1] https://github.com/hokaccha/nodebrew
[1] https://github.com/hokaccha/nodebrew
I prefer n[1], but others might like nvm[2] which is quite similar to rvm.
[1] https://github.com/tj/n [2] https://github.com/creationix/nvm
[1] https://github.com/tj/n [2] https://github.com/creationix/nvm
> 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.
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.
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.)
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.
The GUI has gotten a refresh in recent Windows 10 builds:
http://www.ghacks.net/2015/09/22/microsoft-improves-environm...
http://www.ghacks.net/2015/09/22/microsoft-improves-environm...
Take a look at "rapid environment editor". It solves the " tiny ass box" problem.
I don't think that means "we're screwed." Perhaps npm can now use this LTS as a baseline for v3, since you can upgrade npm separately from Node.
There are still path length issues on Windows, yes.
Here is a stop-gap:
https://www.npmjs.com/package/flatten-packages
Here is a stop-gap:
https://www.npmjs.com/package/flatten-packages
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.
'J' is the first letter without an element name. Maybe a new element will be discovered and given a 'J' name before 2024. :)
https://en.wikipedia.org/wiki/List_of_elements
https://en.wikipedia.org/wiki/List_of_elements
Jargoon?
This is good to hear.
Gonna play hell with seo for my open source projects:
https://github.com/geuis/argon
https://github.com/geuis/helium-css
Gonna play hell with seo for my open source projects:
https://github.com/geuis/argon
https://github.com/geuis/helium-css
Argon is also a password hash function: https://www.cryptolux.org/index.php/Argon
There are a couple regressions in v4.2.0, but v4.2.1 should be out right away with fixes.
[deleted]
"We are proud to announce the release of Node.js v4.2.0 "Ganja", 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?