I hope the node APIs are changed/extended to return promises eventually so I don't have to keep on using promise wrappers for all of them.

Is there a reason you always wrap them? Even if it's awkward I tend to leave most platform APIs alone and treat them as special cases if I'm doing something, say, promises or messages.

Promises are much each to compose. Promise objects can be passed around and reused. (Multiple things can wait on the result of the same promise.) Code is much easier to read with flat .then() and .catch() chains, versus sometimes the "pyramid of doom" callbacks can create. Code is much, much easier to read with Promises when you can use async/await, and getting everything wrapped to promises now makes it that much sooner you can use async/await.

I get the why people want to use Promises in general but when they're used to simply wrap a standard node / browser call feels dirty to me because it changes what you expect it to return (e.g. a promise instead of whatever it normal returns).

I dunno I just don't like to give the impression I'm changing anything about how I'm accessing / using the standard library but I guess this is a bit subjective.

> versus sometimes the "pyramid of doom" callbacks can create

If you structure the code well you never run into this (callback soup is very overblown; if you find yourself in that position then someone screwed something up). But I get promises and async / await are nice :)

Probably in an upcoming Node 6 -- they do update the running version with the latest v8 releases IIRC.

That seems like a mistake to me. That would mean code that runs perfectly under, say, 6.5 would not run on 6.1. It should most certainly be a 7.x release.

This is intentional - it's a feature, not a breaking change, although the docs do identify a greater possibility of regressions until LTS. From https://nodejs.org/en/blog/release/v6.0.0/

> The general rule for deciding which version of Node.js to use is:

> ...

> - Upgrade to Node.js v6 if you have the ability to upgrade versions quickly and want to play with the latest features as they arrive.

> Note that while v6 will eventually transition into LTS, until it does, we will still be actively landing new features (semver-minor). This means that there is an increased chance for regressions to be introduced..

For stability one should be using the LTS release.

And why would one downgrade from 6.5 to 6.1? If they code for 6.1 and want to not use LTS and to keep 6.1 installations around, then they should not use 6.5 features.

It was simply a hypothetical but surely you can imagine a scenario where you either have to downgrade (perhaps a regression happens) or you simply have to target multiple versions. I've run into both situations multiple times in my career.

Regardless yes you should use LTS but that's no excuse for going against semantic versioning. It should be labeled an alpha or beta if they don't want to change major versions for breaking feature additions.

>It was simply a hypothetical but surely you can imagine a scenario where you either have to downgrade (perhaps a regression happens)

Sure, but if you might have to downgrade, then simply don't write code that depends on 6.5 features. 6.5 can still run 6.1 code (feature wise), so you'll be alright.

The only problem would be for people wanting to a) run 6.5, b) take advantage of newer, 6.5-only features, and THEN c) downgrade to 6.1

> Sure, but if you might have to downgrade, then simply don't write code that depends on 6.5 features.

Ah but see that's the rub. Hindsight is always 20/20. I've actually run into similar issues in the past. Ultimately if they're consistent with versions then it's not the biggest deal (because if you have an issue with 6.5 there is probably a good chance you have an issue with 6.1 as well) but with semantic versioning I always expect code written against the major version to always work across all minor versions unless it relied on some weird bug side effect.

It just seems really inconsistent to me.

Really looking forward to this!