1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+
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)
In a real application, using ecosystem packages, it is fine to decide on a fixed target. But, if the core system is moving quickly, chances are the better packages will be moving quickly too. The fear is that there'll be a necessary change in a package (a security issue, or a bug that only surfaces under rare situations, for example), which can cause a cascading upgrade to the whole app. One that needs to be performed quickly.
This has happened to me once, and it wasn't pretty.
It is a concern for any platform, of course, but fast moving ones do 'feel' like they increase the risk. It's therefore a valid question to ask if there are people deploying code in long-term projects, and what the burden is in practice. Since we don't have empirical data (that I know about).
A lot of the Node community does seem to be made up of people creating apps, and enjoying the latest and greatest functionality. There is fewer information from folks running apps long term in mission critical scenarios. That's not a criticism, at all, just an observation: if you are in the latter camp, or considering whether to be, getting good information is harder.
Technical debt, in terms of platform choice, is important.
Because the target user community of what you are writing consists of the kind of users that are likely to use LTS releases.
> Most new packages will probably support the current version, and then your LTS window of 2 years doesnt mean much.
You don't choose LTS because you want support for every new packages that haven't been written yet on the day they come out, you choose LTS because you've got something for which you want to have a stable platform with bug fixes, rather than an unstable platform with breaking changes, and are willing to not have access to the newest platform features or the newest third-party libraries that depend on them to get that stability.
Turns out that despite pillorying Joyent for sticking to V8 major versions, it is the only reasonably-correct thing to do for the ecosystem to remain usable.
No?
Then take your scare quotes and bang your drum elsewhere, because from where I stand, the new boss is pretty much the same as the old boss.
And in 2 years, when we take a peak we see that the changes amassed in between by the non LTS releases are so big we have to pretty much rewrite all of our codebase if we want to continue getting support....
Other apps that require binary add ons required me to install the latest versions from NPM -- one one of them required ANY changes to how the API was called and it was extremely minor.
Waiting 2 years to upgrade the engine your code is running on is not horrible and requires much less pain
I think I'll just add Node 5.0 to CI and see if it passes and that's all there is to it really.
More or Less, Joyent was mostly doing what they were doing for a reason. What the io.js team is doing also has validity but fundamentally you will always see these issues to some extent because of the philosophy behind it.