New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop support for v0.10 and v0.12? #676

Open
bnoordhuis opened this Issue Jun 7, 2017 · 11 comments

Comments

Projects
None yet
4 participants
@bnoordhuis
Member

bnoordhuis commented Jun 7, 2017

(EDIT: Sigh, GH fail. Updated with actual text.)

Per ibmdb/node-ibm_db#276 (comment), 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.

Since this isn't going to be fixed upstream, my suggestion is to make it official that v0.12 is no longer supported and drop support for v0.10 in the process.

@kkoopa

This comment has been minimized.

Collaborator

kkoopa commented Jun 7, 2017

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
@bnoordhuis

This comment has been minimized.

Member

bnoordhuis commented Jun 7, 2017

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.

@kkoopa

This comment has been minimized.

Collaborator

kkoopa commented Jun 7, 2017

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.

@bnoordhuis

This comment has been minimized.

Member

bnoordhuis commented Jun 8, 2017

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

bnoordhuis added a commit to bnoordhuis/fsevents that referenced this issue Jun 8, 2017

Drop io.js v1-3.x from CI.
NAN no longer works with them and they have been out of support for a
long time now.

I don't think we can guarantee things will work with v0.10 and v0.12
either because of nodejs/nan#676.

es128 added a commit to strongloop/fsevents that referenced this issue Jun 8, 2017

Drop io.js v1-3.x from CI.
NAN no longer works with them and they have been out of support for a
long time now.

I don't think we can guarantee things will work with v0.10 and v0.12
either because of nodejs/nan#676.
@mkrufky

This comment has been minimized.

Collaborator

mkrufky commented Jun 8, 2017

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?

@kkoopa

This comment has been minimized.

Collaborator

kkoopa commented Jun 8, 2017

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.

@mkrufky

This comment has been minimized.

Collaborator

mkrufky commented Jun 9, 2017

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?

@kkoopa

This comment has been minimized.

Collaborator

kkoopa commented Jun 9, 2017

es128 added a commit to strongloop/fsevents that referenced this issue Jun 9, 2017

Drop io.js v1-3.x from CI.
NAN no longer works with them and they have been out of support for a
long time now.

I don't think we can guarantee things will work with v0.10 and v0.12
either because of nodejs/nan#676.

es128 added a commit to strongloop/fsevents that referenced this issue Jun 9, 2017

Drop io.js v1-3.x from CI.
NAN no longer works with them and they have been out of support for a
long time now.

I don't think we can guarantee things will work with v0.10 and v0.12
either because of nodejs/nan#676.
@bnoordhuis

This comment has been minimized.

Member

bnoordhuis commented Jun 12, 2017

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.

@kkoopa

This comment has been minimized.

Collaborator

kkoopa commented Jun 14, 2017

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

@ranisalt

This comment has been minimized.

Contributor

ranisalt commented Apr 10, 2018

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 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment