Skip to content
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

Tracking Issue: Node.js 9.0.0 #14391

Closed
jasnell opened this issue Jul 20, 2017 · 26 comments

Comments

Projects
None yet
@jasnell
Copy link
Member

commented Jul 20, 2017

@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

@mscdex mscdex added the v9.x label Jul 20, 2017

@AndreasMadsen

This comment has been minimized.

Copy link
Member

commented Jul 20, 2017

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

@JacksonTian

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2017

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

@seishun

This comment has been minimized.

Copy link
Member

commented Jul 21, 2017

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

@Trott

This comment has been minimized.

Copy link
Member

commented Jul 21, 2017

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

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

@refack

This comment has been minimized.

Copy link
Member

commented Jul 21, 2017

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

#14414

@benjamingr

This comment has been minimized.

Copy link
Member

commented Jul 21, 2017

What version of V8 is this release going to ship?

@targos

This comment has been minimized.

Copy link
Member

commented Jul 21, 2017

@benjamingr It will be 6.1 or 6.2

@SteveCruise

This comment has been minimized.

Copy link

commented Jul 26, 2017

Will then it support import/export?

@XadillaX

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

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

@JacksonTian

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2017

@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

This comment has been minimized.

Copy link
Member

commented Jul 29, 2017

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

@Trott

This comment has been minimized.

Copy link
Member

commented Jul 29, 2017

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

This comment has been minimized.

Copy link
Member

commented Jul 29, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2017

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.

@Trott

This comment has been minimized.

Copy link
Member

commented Aug 1, 2017

@refack @ronkorving Those are interesting points worth considering, although I hesitate to encourage the marshaling of more hypothetical downsides. I think these largely-hypothetical concerns are overruled by the concrete concern of breaking working user code for no tangible gain.

  • I'm unaware of any evidence that a lot of people are running with --no-deprecation to avoid sys deprecation warnings. (For example, it does not seem to come up a lot on StackOverflow or any of our repos.)

  • I'm unaware of any evidence that people are confused by the existence of sys. (For example, it doesn't seem to get asked a lot on StackOverflow or any of our repos.)

  • Without evidence that these are problems users are actually experiencing rather than interesting hypotheticals, these are arguments for theoretical purity.

  • In contrast, it is relatively straightforward to find code in the wild that currently works but that will break if we remove sys. Even if only a small fraction of that code is truly being run by users currently and isn't a false positive, the cost to end users is significant. (This is doubly so if there are users of the code who would not know how to fix it. Triply so if the author no longer maintains said code.) Here's code published 5 hours ago that uses sys.

  • Given the cost to maintainers is near zero, I see no reason to break the code of existing real-world users. If a deprecation warning is not sufficient to move them, then we should leave them alone. (The assessment would change, of course, if this were a significant maintenance burden, a security risk, a buggy module, or something that otherwise inhibits the project. It is none of those.)

@addaleax

This comment has been minimized.

Copy link
Member

commented Aug 4, 2017

Quoting 539f4c0#commitcomment-23478657 by @davidmurdoch:

I'm just hoping for a "Here's whats going to break when you upgrade:" list of .messages that change. I hadn't really taken a good look at other error message changes, but it looks like most of the .message strings will be changing, so maybe this specific list of which changed and which stayed the same won't really be necessary, as we'll all need and want to update most of them anyway to check the .code anyway.

It would probably be nice to compile a list of changed error messages for this release.

@Trott

This comment has been minimized.

Copy link
Member

commented Aug 4, 2017

Speaking of the new internal errror stuff...

I've been neutral on it lately, but I'm starting to wonder more and more if it's worth it.

As I see it, here are the upsides:

  • Provides users with a persistent identifier for errors. Seems good to me.

  • Creates the possibility of one day not having message changes be breaking changes, although no guarantee there. (I consider this a very small benefit. It is not a benefit to our users, really. It is a benefit for us. To me, the burden of having to treat error messages as breaking changes has not been a significant problem given that we release a new major every six months.)

The downsides:

  • Additional complexity for our errors.

  • A whole bunch of breaking changes just to get the thing implemented. (Ecosystem impact is hard to gauge here, but it may be large.)

  • Once we add the code property to errors, we may be stuck with it forever. Once there is significant usage in the ecosystem, it's game over. We can never back out of this system.

I'm not going to object to it unless there are others who feel that way (and even then, I might not object anyway). But as far as I know, there isn't anyone who's uncomfortable with it. But if I'm wrong about that, get in touch, will you? (If there's concern, it would be much better to raise it earlier rather than trying to do it at the last minute. As far as I've been able to tell, no one is concerned except me, and I'm only a little bit concerned.)

@refack

This comment has been minimized.

Copy link
Member

commented Aug 4, 2017

It would probably be nice to compile a list of changed error messages for this release.

I'm working on it, as per @ljharb's idea, to write an npm package that will do Error message to Error code mapping (#13937 (comment))

@ljharb

This comment has been minimized.

Copy link
Member

commented Aug 4, 2017

@refack I'm happy to help with any difficulty you have making it backwards-compatible as far back as possible!

@evanlucas

This comment has been minimized.

Copy link
Member

commented Aug 4, 2017

@Trott I have been a little concerned myself. I think one of the big changes that hasn't really been mentioned is the fact that the code property is no longer writable... I saw err.code = 'some string' just the other day.

@tniessen

This comment has been minimized.

Copy link
Member

commented Aug 5, 2017

Provides users with a persistent identifier for errors. Seems good to me.

I think this outweighs the downsides, unless there is an alternative with the same advantages and without the downsides. Most other programming frameworks provide mechanisms to distinguish errors more or less precisely, and we were really falling behind with very few error classes and relying on error messages. I like how we did not go the JAVA way (I think there are about 400 exception classes in the JRE), especially since JS does not allow to catch only specific errors, and I don't really see an alternative to our approach.

@addaleax

This comment has been minimized.

Copy link
Member

commented Aug 12, 2017

@nodejs/npm It might be good to know, what’s your current schedule for future major npm versions? Is there anything we should be planning for/expecting in time for Node 9?

@refack

This comment has been minimized.

Copy link
Member

commented Sep 8, 2017

#12794 should be in

@refack

This comment has been minimized.

Copy link
Member

commented Oct 10, 2017

Ping @jasnell @nodejs/release
Any RC planned?

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Oct 11, 2017

Yes, planning got out of whack due to Interactive and a surprise customer engagement this week (darned day job!) ... will be getting the RC out as soon as possible this week but struggling to find time.

@apapirovski

This comment has been minimized.

Copy link
Member

commented Dec 6, 2017

@jasnell I believe this can now be closed but let me know if I've made an error or just reopen yourself :)

@apapirovski apapirovski closed this Dec 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.