My only real concern is that doing so would entail a new major release. Major releases are interpreted as breaking changes. Even if we do nothing else and plainly state that there are no actual changes, this still suggests that the new version would have a hard time gaining traction.

So, since major releases are expected to actually be major, I would want to take the opportunity to redesign everything again with lowest support for Node 4.0, incorporating Isolates, Context-passing and a bunch of other stuff. The first problem here is that I do not really have time to do this in a reasonable time. The second is that a lot of the API surface could be reduced, since V8 versions from Node 4 to 8 have been fairly stable. However, that could likely change at some point in the fairly near future, which would require adding a bunch of stuff back in. The third is that it would be fairly pointless, as the napi C++ layer already covers most of that. Due to these problems, a major redesign is not a feasible option.

So, are you suggesting to (choose any number of options):

1. remove any mention of 0.8, 0.10, 0.12 (and io.js) in the documentation
2. remove the code related to 0.8, 0.10, 0.12 (and io.js)
3. change other code
4. something else

As a (choose one option):

1. major release
2. minor release
3. patch release

In that light I'd go for 1, remove any mention of 0.8, 0.10, 0.12 (and io.js) in the documentation.

I wouldn't actually remove all references, just state somewhere where it's clearly visible that interoperability with node.js < v4.x cannot be ensured due to those release lines being out of support (and maybe a note that it's known not to work with newer compilers. Why be coy?)

I don't think we need to bump major for that because it's outside our control. It's not until we start ripping out the support code (option 2) that we need to bump major.

Okay, that sounds reasonable. Then the procedure would be to:

1. Update the documentation in the repository.
2. Include it in the next release, whenever that is (I do not think a documentation change warrants an instant patch release).

I think it is best to still run the tests for all versions until the code under test no longer exists.

@kgryte If you feel strongly enough to dowvote, you might also want to elucidate why.

Is there any plan to add some new functionality that can't be handled in node 0.10 and 0.12? xcode might not compile NAN against 0.12.x, but NAN builds just fine on those embedded linux sdks and slightly older linux distros out there that have old packaged versions of node.

Considering that N-API is going to be the new method for writing native modules for the latest versions of node, I think that leaves NAN mainly to just support the native modules that are already out there. Am I wrong? Is there any reason a developer targeting only the latest versions of node should choose to use NAN instead of N-API?

If NAN drops node 0.12 and 0.10 support, that leaves developers without any options to write new native modules to run on older node versions. Might even compel someone to maintain a NAN fork with continued older node support (gasp!)

My own project, node-dvbtee runs nicely against node 0.10, and I have users that continue to use it against that old node version. I'd feel compelled to pin to an exact NAN version if we were to drop 0.10 & 0.12 support.

So again I ask, is there a real reason to drop this support other than "it appears to be impossible to compile nan against v0.12.x with a recent version of xcode due to a snafu in v8.h" ? Xcode is a big deal, yes... but did we forget about our linux userbase?

There have been longstanding plans for adding such functionality, but they are currently on ice, since the correct way of doing it would entail a lot of work and breaking changes on the scale of NAN 1 -> 2. But, if there ever is a NAN 3, it will definitely not acknowledge anything older than Node 4.

Nothing would change for the foreseeable future, except that bug reports pertaining to unsupported versions will be ignored and no real effort would be made to make new features work on those versions.

As I mentioned somewhere else, N-API is not meant to be directly used for anything. Where has this notion come from? It is an (effectively internal) low-level infrastructure layer meant to offer ABI stability. There will be another layer on top.

Using Node 0.8, 0.10 or 0.12 is already at your own risk, since they are not supported. NPM does not even support Node 0.12 any more. The same would apply to NAN. What has worked until now should continue working for the foreseeable future, it is just that there are no guarantees.

Dropping the old node versions makes sense for NAN 3, but I'd be sad to see this happen for NAN 2.

Meanwhile, if we're not actually going to break the support for 0.10.x and 0.12.x, just updating the docs to remove mention of the older versions, that seems OK.

I also think it's best to still run the tests for all versions until the code under test no longer exists.

So we still wont actually break the 0.10 & 0.12 support until NAN 3?

As another data point, node-gyp is about to drop support for <= v4.x. The world is moving on.

So we still wont actually break the 0.10 & 0.12 support until NAN 3?

That raises an interesting point: do we allow C++11 in new code? That doesn't break working code as such but it does force users to upgrade their compilers if they're still stuck on old compilers.

C++11 should be perfectly fine, since no new code will be written for versions below 4.

That doesn't break working code as such but it does force users to upgrade their compilers if they're still stuck on old compilers

It is worth mentioning the oldest GCC version I could find on still supported Linux distros is Ubuntu 14.04 with GCC 4.8, the first one with full C++11 support. So unless one has an utterly, awfully outdated OS, you shouldn't worry 😄