Node: Planning for v6

Created on 17 Mar 2016  ·  69Comments  ·  Source: nodejs/node

@nodejs/ctc @nodejs/lts - It's almost time to begin preparing the v6 release. What schedule do we want to target? I volunteer to do the actual release.

A quick run on changelog-maker looking at all semver-major changes since v5.0.0 was cut shows 48 semver-major commits:

This, of course, does not include the v8 updates.

(BTW, According to changelog-maker, there have been around 1023 commits in master since v5.0.0 was tagged.)

meta
Source
picture jasnell
🎉34 👍21

Most helpful comment

Ok. Let's definitely do that then. How's this proposed tentative schedule?

  • April 12th - First v6 RC with v8 5.0 beta
  • April 19th - Second v6 RC with v8 5.0 stable
  • April 26th - v6 Release

We can throw additional RCs in if necessary but I'd want at least two.
On Mar 18, 2016 6:26 AM, "Michael Dawson" [email protected] wrote:

V8 has dev, beta and stable. 5.0 is already in 'beta" so its better than
"dev" but as @bnoordhuis https://github.com/bnoordhuis mentions there
could be last minute changes, although I think the likelihood on a API
change is small, particularly as it gets close to the end of the beta
period.

I'm + 1 on aiming for 5.0

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5766#issuecomment-198354429

picture jasnell on 18 Mar 2016
👍29 😄5

All 69 comments

I'll handle writing up a more detailed breaking changes document shortly, just like I did for v4.

Fishrock123 picture Fishrock123 on 17 Mar 2016
👍4

I'll spin up work on Promises again next week so I can give a status report on where they're at.

chrisdickinson picture chrisdickinson on 17 Mar 2016
👍1

cc @nodejs/v8 what version of v8 do we figure might be able to land in this?

Fishrock123 picture Fishrock123 on 17 Mar 2016

As a note, we should aim for mid April, late April at latest.

Fishrock123 picture Fishrock123 on 17 Mar 2016
👍1

+1 for mid April.

jasnell picture jasnell on 17 Mar 2016

I would suggest targeting late April to make sure we can land V8 5.0.

ofrobots picture ofrobots on 17 Mar 2016
👍26 ❤4

@ofrobots ... what's the current target date for v8 5.0?

jasnell picture jasnell on 17 Mar 2016

@jasnell The release page points to April 19th. End of April sounds like enough time to do a few RCs once it is 'officially' stable.

jbergstroem picture jbergstroem on 17 Mar 2016

Oh! I forgot there was a published release page ;) OK, that should work. We
might even be able to get away with cutting a RC before it goes stable as
long as it's close.
On Mar 17, 2016 3:11 PM, "Johan Bergström" [email protected] wrote:

@jasnell https://github.com/jasnell The release page
http://www.chromium.org/developers/calendar points to April 19th. End
of April sounds like enough time to do a few RCs once it is 'officially'
stable.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5766#issuecomment-198104768

jasnell picture jasnell on 17 Mar 2016

As the release page mentions, April 19th is the _estimated_ target date. Fine print:

These dates are subject to change without advance notice and provided here only for rough planning purposes. New bugs, security incidents, holiday schedules, partner dependencies and process changes can all affect these dates and move it in either direction. The date only estimates the week of 1st stable push of a release – it does not imply that all end points will be updated by this week.

ofrobots picture ofrobots on 17 Mar 2016

Yep, fine print understood. We definitely should try to get v5 in so let's
hope it doesn't slip.
On Mar 17, 2016 3:18 PM, "Ali Ijaz Sheikh" [email protected] wrote:

As the release page mentions, April 19th is the _estimated_ target date.
Fine print:

These dates are subject to change without advance notice and provided here
only for rough planning purposes. New bugs, security incidents, holiday
schedules, partner dependencies and process changes can all affect these
dates and move it in either direction. The date only estimates the week of
1st stable push of a release – it does not imply that all end points will
be updated by this week.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5766#issuecomment-198106689

jasnell picture jasnell on 17 Mar 2016

@jasnell if their are RC releases for v5 of v8... would we not be able to cut an RC with that?

MylesBorins picture MylesBorins on 18 Mar 2016

V8 doesn't have RCs, their development model is "it's unstable (API-wise) until the release branch is cut." I think it's fine to do a RC with a V8 development snapshot as long as we make it well-understood that there can be last-minute changes before the 6.0 GA.

BTW, I agree we should aim for V8 5.0.

bnoordhuis picture bnoordhuis on 18 Mar 2016

V8 has dev, beta and stable. 5.0 is already in 'beta" so its better than "dev" but as @bnoordhuis mentions there could be last minute changes, although I think the likelihood on a API change is small, particularly as it gets close to the end of the beta period.

I'm + 1 on aiming for 5.0

mhdawson picture mhdawson on 18 Mar 2016

Ok. Let's definitely do that then. How's this proposed tentative schedule?

  • April 12th - First v6 RC with v8 5.0 beta
  • April 19th - Second v6 RC with v8 5.0 stable
  • April 26th - v6 Release

We can throw additional RCs in if necessary but I'd want at least two.
On Mar 18, 2016 6:26 AM, "Michael Dawson" [email protected] wrote:

V8 has dev, beta and stable. 5.0 is already in 'beta" so its better than
"dev" but as @bnoordhuis https://github.com/bnoordhuis mentions there
could be last minute changes, although I think the likelihood on a API
change is small, particularly as it gets close to the end of the beta
period.

I'm + 1 on aiming for 5.0

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5766#issuecomment-198354429

jasnell picture jasnell on 18 Mar 2016
👍29 😄5

V8 5.0 is a reasonable target. :)

john-yan picture john-yan on 18 Mar 2016
👍1

@jasnell Perhaps RC2 should be moved a day, to April 20th? Even if v8 5.0 hits stable on April 19th, it's not guaranteed that it won't happen at 23:50.

ChALkeR picture ChALkeR on 19 Mar 2016

@jasnell I don't see https://github.com/nodejs/node/pull/5167 in the list. As discussed in https://github.com/nodejs/node/issues/3804 it should be included, to remove Windows XP and Vista support.

joaocgreis picture joaocgreis on 21 Mar 2016

@joaocgreis ... I think that actually landed while I was putting the list above together. The list certainly is not comprehensive as there are other pending semver-majors that need to be included as well. Once we're a bit closer I'll update the list again.

jasnell picture jasnell on 21 Mar 2016

If there are other PRs that need to land, please tag them with the 6.0.0 milestone. :)

Fishrock123 picture Fishrock123 on 22 Mar 2016

Added 6.0.0 milestone to https://github.com/nodejs/node/pull/5707

Trott picture Trott on 22 Mar 2016

Was just brought up on my end, but as reminder we also need to ensure NAN is 100% working with v8 5.0.

Fishrock123 picture Fishrock123 on 23 Mar 2016

@jasnell

Re:

  • [2c55cc2] - (SEMVER-MAJOR) buffer: remove deprecated Buffer.write branch ([email protected]) #5048

We've gotten this in our stderr for quite some time _(probably a year or less)_ and I've hunted in our project to see if we use it but it appears that we don't. I am left to guess that it's one of our _(currently 54)_ dependencies.

Two questions come to mind here...

  1. How do I find it so I can go make/check an issue on that dependency? _($ grep isn't forthcoming as this is probably one of the more common Buffer methods in just about every project and I've been hunting off and on for months now hoping it would self-heal on a dep update somewhere)_.
  2. Since #5048 is already merged somewhere in the tree and this issue is about v6 is it going to break something when we get there?

Please help... anyone too. :) Thanks.

Additional note: OpenUserJS/OpenUserJS.org@0214d06/libs/githubClient.js#L52 does contain an encoding on construction _(search here yielded this)_... but the error thrown indicates .write... so that is a bit confusing if this is the issue on our end. _(our Code is small comparatively so there aren't many search results)_

Martii picture Martii on 25 Mar 2016

@Martii Sounds like you're looking for either the --trace-deprecation, or --throw-deprecation flag.

Fishrock123 picture Fishrock123 on 29 Mar 2016

@Fishrock123
_Major Thank YOU!!!_ ... finds it right out... sorry about the noobie'ish question. :) Time to go study that page.

Martii picture Martii on 29 Mar 2016

Are we going to do benchmarks to check for performance regressions, especially considering the v8 upgrade? I assume the answer is "yes" but you know what they say about assumptions...

/cc @nodejs/benchmarking @mhdawson @mscdex

Trott picture Trott on 6 Apr 2016

I just built and ran NAN's test suite against the vee-eight-5.0 branch. No warnings, no errors, no problems.

I understand the MakeCallback changes mentioned in https://github.com/nodejs/nan/issues/548 have not yet made it in there. If I were you, I would strongly reconsider breaking the signature. Is it not so that AsyncWrap is an internal class? Could you not leave the signature of MakeCallback unchanged and only change AsyncWrap to return a MaybeLocal, then have MakeCallback throw if the return value is Empty?

While NAN's test suite is far from complete, it does cover a sizeable chunk, in addition to the fact that the entire library compiles. More extensive testing is of course appropriate once release candidates start rolling out. I'm confident someone will take care of that.

I had originally envisioned doing a NAN 3.0 release with some breaking changes for Node 6, but it looks like that might not be necessary. This could potentially be the smoothest transition in years. The main cause for concern is if V8 deprecates or changes something in the middle of major version 5.

kkoopa picture kkoopa on 6 Apr 2016

@kkoopa The reason I wanted to change the interface was for consistency. Currently users of node::MakeCallback() have no way of knowing if the call threw. But i'm also not bent on making the change, so if it's decided that con's out weight the pro's then I won't loose any sleep.

trevnorris picture trevnorris on 7 Apr 2016

@trevnorris Gotcha, and I agree that the change is correct and warranted. As you duly noted, the question is about the timing within the bigger picture.

Things to consider, which are not only related to MakeCallback. For example, https://github.com/nodejs/nan/pull/490 needs to happen at some point:

  • Cost of changing versus cost of compatibility, as well as gains from both sides
  • Is Node 6 going to be a "stable" release? How long will we have to live with the choices made now?
  • Is it going to be LTS?
  • When is 0.10 being put down for good?
  • Is module registration being changed? I think I saw an issue or pull request related to that. I have
    https://github.com/nodejs/nan/pull/489/commits/5f77093470873f40217a68b7239d03d9b81651ef in mind, which would be cleaner than the current NAN_MODULE_INIT hack, which was added at the last minute (It's related to Handle deprecation in V8)
  • What will change in V8 during active development of Node 6 and future versions?

Personally, I am indifferent as to what happens, especially if I don't have to do too much myself.
However, my impression from the community regarding native addons is that the past years' significant changes have finally settled down. It might be too early to stir the pot again.

On the other hand, many the majority of addons still use soon to be deprecated (maybe already removed) V8 APIs, like Object::Set and a whole bunch of others which are still being phased out as part of the Maybe API transition. NAN has had that covered ever since version 2.0, but many developers have not paid attention to it. It might be that some of this has been deprecated or removed in V8 5.0, or will be removed later in the 5-series. If that is the case, the majority of addons will still require rewriting, as they have not been future-proofed.

All of these aspects should be accounted for when deciding what to do with Node 6. There might also be additional concerns I could not think of right now.

kkoopa picture kkoopa on 7 Apr 2016
👍1

@Trott when v8 is updated in master the night nightly run of the benchmarks will give us some info. Once we cut 6 I'm also planning to add that release as one of the releases we run the benchmarks displayed on benchmarking.nodejs.org on each night.

mhdawson picture mhdawson on 7 Apr 2016

@kkoopa to your questions, v6 is going to turn in to LTS in October this year, so the choices we make now wrt breaking changes are going to have a long-term impact. v0.10 is going to be killed off at approximately the same time, tho I expect it to linger in use like 0.8 did so we shouldn't be too keen to stick the knife in to it. I really don't have an opinion on which way the MakeCallback change should go but if we think it's a good thing to do _at some point_, perhaps that point should be now as we'll be stuck supporting the API as it gets baked in now for the next 3 years (and a little more given the way people hang on to older versions).

rvagg picture rvagg on 7 Apr 2016

@jasnell It's possible I may edit my unrefed stuff still before it lands anywhere, so if you could either not document, or include (your digression) https://github.com/nodejs/node/commit/7d8882ba9a8cfc8f0e2126deb3f3df7456de0ffa, that'd be great.

(If it changes between the RC's I'm not too concerned. It's "internal" anyways, but some people may be concerned.)

Fishrock123 picture Fishrock123 on 11 Apr 2016

Ended up with a personal scheduling conflict this morning that's put me behind schedule today. Still hoping to get v6 RC1 out today but it's looking increasingly less likely. It may very well go out tomorrow.

jasnell picture jasnell on 11 Apr 2016
👍2

@jasnell Any development this week? We're waiting to upgrade.

mstdokumaci picture mstdokumaci on 19 Apr 2016

There will be a new RC.3 coming today. The actual release is scheduled for
Tuesday the 26th.
On Apr 19, 2016 12:17 AM, "Mustafa Dokumacı" [email protected]
wrote:

@jasnell https://github.com/jasnell Any development this week? We're
waiting to upgrade.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5766#issuecomment-211768103

jasnell picture jasnell on 19 Apr 2016
👍8 🎉4

Not sure if it's the best place to post it but I found the v6 RCs are breaking a popular david package; details in #6297.

mgol picture mgol on 20 Apr 2016

I'd like to know from the CTC whether an upgrade to the OSX Installer would be considered breaking. It was supposed to get in to master before v6 but it's slipped (mostly my fault) and I wouldn't mind getting it in during v6 Stable. However, it's a totally new installer even though it still uses the same OSX .pkg system. I don't _think_ there would be problems if people were somehow automating using it but there will be a different experience for people installing it.

/cc @fhemberger

rvagg picture rvagg on 20 Apr 2016

Would it be reasonable to also provide builds with the existing installer
in parallel for a month or two? Just in case anyone ends up having an issue
with the installer they would have a fallback. If we can do that then I'd
say +1 to landing in v6 stable.
On Apr 20, 2016 7:55 AM, "Rod Vagg" [email protected] wrote:

I'd like to know from the CTC whether an upgrade to the OSX Installer
would be considered breaking. It was supposed to get in to master before v6
but it's slipped (mostly my fault) and I wouldn't mind getting it in during
v6 Stable. However, it's a totally new installer even though it still uses
the same OSX .pkg system. I don't _think_ there would be problems if
people were somehow automating using it but there will be a different
experience for people installing it.

/cc @fhemberger https://github.com/fhemberger

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5766#issuecomment-212460853

jasnell picture jasnell on 20 Apr 2016

Since the installer is not used programmatically and the final results should be the same, an new installer strikes me as potentially Semver Minor, if the only changes to the users installer experience are new features.

Funny enough I was thinking about this just before seeing this comment, specifically about how I hoped changes to the installer (potentially breaking ones) could get into v6 prior to lts

MylesBorins picture MylesBorins on 20 Apr 2016

Should we make a checklist of things that must be done by release time?

evanlucas picture evanlucas on 20 Apr 2016

@evanlucas Sounds beneficial, especially so that everyone is on the same page

mscdex picture mscdex on 20 Apr 2016

At this point this is what I have...

  • [ ] - Smoke testing everything as much as possible. @TheAlphaNerd has been running ctigm on master and a few regressions have been caught, but we need people to help test more.
  • [ ] - Smoke testing npm on master. Are we absolutely certain that npm on master is working correctly? /cc @zkat @iarna @othiym23
  • [ ] - Compiling the Notable Changes. This should be in terms of Notable changes since v5.10.1, and Notable semver-major changes since v4.0
  • [ ] - We have a handful of outstanding issues marked on the v6 milestone here that need resolving: https://github.com/nodejs/node/milestones/6.0.0
  • [ ] - PR? I know the Linux Foundation is planning something and I'm working on a blog post or two (or three :-/ ...). Who else is writing what?
  • [ ] - Update ES6 Page on nodejs.org (https://github.com/nodejs/nodejs.org/issues/671)

What else needs to be on this list?

jasnell picture jasnell on 20 Apr 2016

@jasnell https://github.com/nodejs/nodejs.org/issues/671. The ES6 page will need to be updated for v6 as well

evanlucas picture evanlucas on 20 Apr 2016

@evanlucas .. added to the list! thanks!

jasnell picture jasnell on 20 Apr 2016

Can https://github.com/nodejs/node/pull/5950 get a v6 tag?

dlongley picture dlongley on 21 Apr 2016

@dlongley ... it's now on the list!

jasnell picture jasnell on 21 Apr 2016
👍4

Two more for the list: #6320 and #6277.

ofrobots picture ofrobots on 21 Apr 2016

cc @crandmck

piscisaureus picture piscisaureus on 21 Apr 2016

5731 is for dropping older OS X versions in 6.0, so I set a «6.0.0» milestone to it.

ChALkeR picture ChALkeR on 23 Apr 2016

Are things on track for v6 tomorrow? We're looking to upgrade some boxes. Cheers 👍

ThomasLomas picture ThomasLomas on 25 Apr 2016

Yes. It'll be tomorrow, likely around early afternoon Pacific time.
On Apr 25, 2016 2:17 AM, "Thomas Lomas" [email protected] wrote:

Are things on track for v6 tomorrow? We're looking to upgrade some boxes.
Cheers 👍

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/nodejs/node/issues/5766#issuecomment-214223076

jasnell picture jasnell on 25 Apr 2016

@jasnell That means that the milestone date is off.

ChALkeR picture ChALkeR on 25 Apr 2016

It's better to be early than late ;)

targos picture targos on 25 Apr 2016
👍6

v6 will require NODE_MODULE_VERSION to be bumped, right? As far as I can tell, at least #4106 was a breaking change for native modules…
I’m running into symbol lookup errors inside Isolate::AdjustAmountOfExternalAllocatedMemory, which introduced Isolate::ReportExternalAllocationLimitReached and removed Isolate::CollectAllGarbage (which makes sense given the diff).

addaleax picture addaleax on 25 Apr 2016

Shouldn't no, NODE_MODULE_VERSION was bumped to 47 for v5.0.0. And since there are no breaking API/ABI changes in v8 v5 in v6 ( ... ;-) ...) then we shouldn't need to bump the NODE_MODULE_VERSION at all.

jasnell picture jasnell on 25 Apr 2016

@jasnell Sorry if I’m being naïve, but in what way does removing an exported symbol in v6 that is referenced in v5.x’s version of the v8.h not constitute a breaking ABI change?

addaleax picture addaleax on 25 Apr 2016

@jasnell While there are no _breaking_ API changes, there _are_ ABI changes between V8 4.6 and 5.0.
EDIT: added breaking.

ofrobots picture ofrobots on 25 Apr 2016

Between 4.6 and 5.0, yes, but what about between 4.7 and 5.0? The NODE_MODULE_VERSION was bumped in v5.0.0.

@addaleax ... it might just be me ;-) I'm not exactly certain when that particular change was made.

jasnell picture jasnell on 25 Apr 2016

@jasnell Nodes.js 5.x has V8 4.6 (last time I checked).

ofrobots picture ofrobots on 25 Apr 2016 
$ nvm use 5 && node -p process.versions.v8
Now using node v5.11.0
4.6.85.31

Sorry, yup. @ofrobots Do you know from the top of your head how extensive those ABI changes are? The one I encountered is probably more or less fixable by creating a shim for the removed function that just calls the newly introduced one.

addaleax picture addaleax on 25 Apr 2016

ah right... sigh, too much bouncing back and forth between versions. Ok, looks like we'll definitely need to bump that then. /cc @rvagg

jasnell picture jasnell on 25 Apr 2016

@addaleax While I don't expect that the ABI changes to be very extensive, each ABI changes needs to be looked at independently. Here's the a diff of include/v8.h from branch-heads/4.6 to branch-heads/5.0: https://gist.github.com/ofrobots/40d1f40b89047250eac2fc78f51bc777. There are a bunch of constant changes (e.g. FunctionCallbackInfo layout), etc. I haven't gone through this in detail.

ofrobots picture ofrobots on 25 Apr 2016

@ofrobots Thanks, I’ll take a look.

addaleax picture addaleax on 25 Apr 2016

Meh, the member fields of EscapableHandleScope changed, I think that settles it. It’s a shame though, there was really not much that looked like it would actually break things.

addaleax picture addaleax on 25 Apr 2016

@Fishrock123, @jasnell, does this still need a ctc-agenda label? I don't think there would be another CTC meeting before the release.

ChALkeR picture ChALkeR on 25 Apr 2016

It would probably be good if we could get https://github.com/nodejs/node/pull/6375 in. (I'm really sorry it is so late..)

Reasoning is in https://github.com/nodejs/promises/issues/26#issuecomment-188867688, and I've effectively signed myself up to take any blame from it. 😬

Fishrock123 picture Fishrock123 on 26 Apr 2016
👍3

need to investigate https://github.com/nodejs/node/pull/6382 before v6 goes out otherwise we'll be shipping with a broken API

Other option: revert both commits

Fishrock123 picture Fishrock123 on 26 Apr 2016

@Fishrock123 ... ok, let me know how you want to proceed with it.

jasnell picture jasnell on 26 Apr 2016

Ok, closing this now that the Release Proposal PR is open here https://github.com/nodejs/node/pull/6383

Please make sure that everything that needs to be included in v6 is added to the 6.0.0 milestone or there's a good change it'll end up getting overlooked. Thanks all!

jasnell picture jasnell on 26 Apr 2016
Was this page helpful?
0 / 5 - 0 ratings

Related issues

Icemic picture Icemic  ·  3Comments
dfahlander picture dfahlander  ·  3Comments
danialkhansari picture danialkhansari  ·  3Comments
akdor1154 picture akdor1154  ·  3Comments
Brekmister picture Brekmister  ·  3Comments