Tracking Issue: Node.js 9.0.0

[jasnell]

@nodejs/collaborators @nodejs/ctc,

It feels like only yesterday that I was preparing the 8.0.0 release! Time flies!

I plan to begin working on the 9.0.0 release in early September, with an eye towards release by the end of October. The v9.x and v9.x-staging branches will be cut the first or second week of September, with an estimated semver-major freeze by September 30th. Beta releases will be cut once per week in September, with a roll over to RC's in October. I'd really like to avoid last minute major updates so please try to get any semver-major updates, significant dependency updates, etc in by the September 30th deadline.

For any PR that needs to land for 9.x, I would appreciate if you would assign it to the 9.x milestone for easier tracking.

/cc @nodejs/release

[AndreasMadsen]

I think we should remove the async_hooks deprecated API in this release.
/cc @nodejs/async_hooks

[JacksonTian]

I think we should remove the sys deprecated module in this release.

[seishun]

I think we should revisit Buffer constructor deprecation in this release.

[Trott]

I think we should remove the sys deprecated module in this release.

Why? What harm does it do to leave it there?

[refack]

I think we should remove the async_hooks deprecated API in this release.
/cc @nodejs/async_hooks

#14414

[benjamingr]

What version of V8 is this release going to ship?

[targos]

@benjamingr It will be 6.1 or 6.2

[SteveCruise]

Will then it support import/export?

[XadillaX]

I would like to deprecate tls.parseCertString() in runtime via #14249

[JacksonTian]

@Trott

commit b28e700ebdf6583364fec3171390a24153f79632
Author: Ryan Dahl <ry@tinyclouds.org>
Date:   Mon Jan 9 12:59:26 2012 -0800

    require('sys') now throws
    
    To be removed in v0.9

It's planed in v0.9, so I think remove it at 9.x is make sense.

[addaleax]

@JacksonTian The commit you are referencing was reverted, the current state of deprecation has been introduced in dc42e1f (2015).

[Trott]

The cost to us of keeping sys around is nearly zero and is surely less than the cost to end users if we were to remove it entirely.

For some historical background:

The idea that we are probably never going to remove sys entirely has been the position of the project since deprecating, and I don't think anything has changed that would alter that.

From January 2015 when sys was run-time deprecated, @bnoordhuis addressing the issue of when sys will be removed altogether:

Probably never. It's not broken and it's not a maintenance burden. Even a deprecation message is somewhat debatable but deprecation messages can be disabled if you really must; at least it shoos people away from using 'sys' in new code.

That sentiment is echoed by @piscisaureus, @chrisdickinson, and @indutny in the Technical Committee meeting just prior to that where the issue was discussed.

[refack]

Probably never. It's not broken and it's not a maintenance burden. Even a deprecation message is somewhat debatable but deprecation messages can be disabled if you really must; at least it shoos people away from using 'sys' in new code.

That sentiment is echoed by @piscisaureus, @chrisdickinson, and @indutny in the Technical Committee meeting just prior to that where the issue was discussed.

So, I see a hidden cost in above statement — people who use sys and are comfortable with it's use might decide to use --no-deprecation CLI arg, thus hiding other, more "significant" warnings... (yes I know I'm reaching here)

[ronkorving]

I think there is the cost of confusion. People who read code that uses sys for the first time, will be (rightfully) confused and will now be expected to go and look up to see what's right according to the Node manual. It's that, or stay confused. Or worse: assume the wrong answer.

I for one want Node to be intuitive as well as easy to understand.