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

Planning for v6 #5766

Closed
jasnell opened this issue Mar 17, 2016 · 69 comments

Comments

Projects
None yet
@jasnell
Copy link
Member

commented Mar 17, 2016

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

  • [85ab4a5] - (SEMVER-MAJOR) buffer: add .from(), .alloc() and .allocUnsafe() (James M Snell) #4682
  • [2c55cc2] - (SEMVER-MAJOR) buffer: remove deprecated Buffer.write branch (dcposch@dcpos.ch) #5048
  • [101bca9] - (SEMVER-MAJOR) buffer: remove deprecated buffer.get/.set methods (Feross Aboukhadijeh) #4594
  • [3b27dd5] - (SEMVER-MAJOR) buffer: throw if both length and enc are passed (Mathias Buus) #4514
  • [90a5fc2] - (SEMVER-MAJOR) build: remove lint/dotfiles from release tarball (Johan Bergström) #5695
  • [66f4586] - (SEMVER-MAJOR) cluster: emit worker as first 'message' event arg (Ben Noordhuis) #5361
  • [a5cce79] - (SEMVER-MAJOR) console: delete timers that have ended (Vladimir Varankin) #3562
  • [a37401e] - (SEMVER-MAJOR) crypto: simplify Certificate class bindings (Alexander Makarenko) #5382
  • [7c48cb5] - (SEMVER-MAJOR) crypto: Improve control of FIPS mode (Stefan Budeanu) #5181
  • [a116358] - (SEMVER-MAJOR) crypto: pbkdf2 deprecate digest overload. (Tom Gallacher) #4047
  • [b010c87] - (SEMVER-MAJOR) crypto, string_bytes: treat buffer str as utf8 (Fedor Indutny) #5522
  • [dbdbdd4] - (SEMVER-MAJOR) dns: add resolvePtr to query plain DNS PTR records (Daniel Turing) #4921
  • [c4ab861] - (SEMVER-MAJOR) dns: add failure test for dns.resolveXXX (Daniel Turing) #4921
  • [f3be421] - (SEMVER-MAJOR) dns: coerce port to number in lookupService (Evan Lucas) #4883
  • [d829028] - (SEMVER-MAJOR) doc: document deprecation of util._extend (Benjamin Gruenbaum) #4903
  • [90204cc] - (SEMVER-MAJOR) domains: clear stack when no error handler (Julien Gilli) #4659
  • [8bb60e3] - (SEMVER-MAJOR) fs: improve error message for invalid flag (James M Snell) #5590
  • [1d79787] - (SEMVER-MAJOR) fs: add a temporary fix for re-evaluation support (Сковорода Никита Андреевич) #5102
  • [1124de2] - (SEMVER-MAJOR) fs: deprecate fs.read's string interface (Sakthipriyan Vairamani) #4525
  • [2b15e68] - (SEMVER-MAJOR) fs: fs.read into zero buffer should not throw exception (Feross Aboukhadijeh) #4518
  • [8b97249] - (SEMVER-MAJOR) fs: fix the error report on fs.link(Sync) (yorkie) #3917
  • [d01eb68] - (SEMVER-MAJOR) lib: add 'pid' prefix in internal/util (Minwoo Jung) #3878
  • [20285ad] - (SEMVER-MAJOR) lib: Consistent error messages in all modules (micnic) #3374
  • [94b9948] - (SEMVER-MAJOR) lib,src: ensure '(node:pid)' prefix for stdout logging (Minwoo Jung) #3833
  • [b70dc67] - (SEMVER-MAJOR) lib,test: remove publicly exposed freelist (cjihrig) #3738
  • [71470a8] - (SEMVER-MAJOR) module: pass v8::Object to linked module initialization function (Phillip Kovalev) #4771
  • [18490d3] - (SEMVER-MAJOR) module: always decorate thrown errors (Brian White) #4287
  • [a78b334] - (SEMVER-MAJOR) net: type check createServer options object (Sam Roberts) #2904
  • [25751be] - (SEMVER-MAJOR) node: deprecate process.EventEmitter (Evan Lucas) #5049
  • [d1000b4] - (SEMVER-MAJOR) path: make format() consistent and more functional (Nathan Woltman) #2408
  • [72e3dd9] - (SEMVER-MAJOR) process: throw on non-function to nextTick() (yorkie) #3860
  • [ca2e8b2] - (SEMVER-MAJOR) readline: deprecate undocumented exports (cjihrig) #3862
  • [5700352] - (SEMVER-MAJOR) src: attach error to stack on displayErrors (cjihrig) #4874
  • [bfb2cd0] - (SEMVER-MAJOR) stream: add bytesRead property for readable (Jackson Tian) #4372
  • [cc0342a] - (SEMVER-MAJOR) streams: update .readable/.writable to false (Brian White) #4083
  • [5f76b24] - (SEMVER-MAJOR) http: overridable clientError (Fedor Indutny) #4557
  • [a5aa7c1] - (SEMVER-MAJOR) test: expand test case for unknown file open flags (James M Snell) #5590
  • [2c33819] - (SEMVER-MAJOR) test: fix tests that check error messages (cjihrig) #3727
  • [ac153bd] - (SEMVER-MAJOR) timers: fail early when callback is not a function (Anna Henningsen) #4362
  • [1ab6b21] - (SEMVER-MAJOR) tls: rename clientError to tlsClientError (Fedor Indutny) #4557
  • [df268f9] - (SEMVER-MAJOR) tls: use SHA1 for sessionIdContext (Stefan Budeanu) #3866
  • [a2c0aa8] - (SEMVER-MAJOR) tty: Remove deprecated setRawMode wrapper (Wyatt Preul) #2528
  • [e2f47f5] - (SEMVER-MAJOR) util: Change how Error objects are formatted (Mudit Ameta) #4582
  • [93d6b5f] - (SEMVER-MAJOR) util: use consistent Dates in inspect() (Xotic750) #4318
  • [24012a8] - (SEMVER-MAJOR) util: make inspect more reliable (Evan Lucas) #4098
  • [007cfea] - (SEMVER-MAJOR) util: remove pump (Wyatt Preul) #2531
  • [4cf19ad] - (SEMVER-MAJOR) util: Remove exec, has been deprecated for years (Wyatt Preul) #2530
  • [34a3591] - (SEMVER-MAJOR) util: improve typed array formatting (Ben Noordhuis) #3793

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.)

@jasnell jasnell added the meta label Mar 17, 2016

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Mar 17, 2016

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

@chrisdickinson

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2016

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

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Mar 17, 2016

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

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Mar 17, 2016

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

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Mar 17, 2016

+1 for mid April.

@ofrobots

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2016

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

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Mar 17, 2016

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

@jbergstroem

This comment has been minimized.

Copy link
Member

commented Mar 17, 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.

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Mar 17, 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" notifications@github.com 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
#5766 (comment)

@ofrobots

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 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.

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Mar 17, 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" notifications@github.com 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
#5766 (comment)

@MylesBorins

This comment has been minimized.

Copy link
Member

commented Mar 17, 2016

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

@bnoordhuis

This comment has been minimized.

Copy link
Member

commented Mar 18, 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.

@mhdawson

This comment has been minimized.

Copy link
Member

commented Mar 18, 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

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Mar 18, 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" notifications@github.com 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
#5766 (comment)

@john-yan

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2016

V8 5.0 is a reasonable target. :)

@ChALkeR

This comment has been minimized.

Copy link
Member

commented Mar 19, 2016

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

@joaocgreis

This comment has been minimized.

Copy link
Member

commented Mar 21, 2016

@jasnell I don't see #5167 in the list. As discussed in #3804 it should be included, to remove Windows XP and Vista support.

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Mar 21, 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.

@Fishrock123 Fishrock123 added this to the 6.0.0 milestone Mar 22, 2016

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Mar 22, 2016

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

@Trott

This comment has been minimized.

Copy link
Member

commented Mar 22, 2016

Added 6.0.0 milestone to #5707

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Mar 23, 2016

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

@Martii

This comment has been minimized.

Copy link

commented Mar 25, 2016

@jasnell

Re:

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)

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Mar 29, 2016

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

@Martii

This comment has been minimized.

Copy link

commented Mar 29, 2016

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

@evanlucas

This comment has been minimized.

Copy link
Member

commented Apr 20, 2016

@jasnell nodejs/nodejs.org#671. The ES6 page will need to be updated for v6 as well

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Apr 20, 2016

@evanlucas .. added to the list! thanks!

@dlongley

This comment has been minimized.

Copy link

commented Apr 20, 2016

Can #5950 get a v6 tag?

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Apr 20, 2016

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

@ofrobots

This comment has been minimized.

Copy link
Contributor

commented Apr 21, 2016

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

@piscisaureus

This comment has been minimized.

Copy link
Member

commented Apr 21, 2016

@ChALkeR

This comment has been minimized.

Copy link
Member

commented Apr 23, 2016

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

@ThomasLomas

This comment has been minimized.

Copy link

commented Apr 25, 2016

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

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 2016

Yes. It'll be tomorrow, likely around early afternoon Pacific time.
On Apr 25, 2016 2:17 AM, "Thomas Lomas" notifications@github.com 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
#5766 (comment)

@ChALkeR

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

@jasnell That means that the milestone date is off.

@targos

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

It's better to be early than late ;)

@addaleax

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

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).

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 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.

@addaleax

This comment has been minimized.

Copy link
Member

commented Apr 25, 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?

@ofrobots

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2016

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

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 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.

@ofrobots

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2016

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

@addaleax

This comment has been minimized.

Copy link
Member

commented Apr 25, 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.

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Apr 25, 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

@ofrobots

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 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.

@addaleax

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

@ofrobots Thanks, I’ll take a look.

@addaleax

This comment has been minimized.

Copy link
Member

commented Apr 25, 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.

@ChALkeR

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

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

@jasnell jasnell removed the ctc-agenda label Apr 25, 2016

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

It would probably be good if we could get #6375 in. (I'm really sorry it is so late..)

Reasoning is in nodejs/promises#26 (comment), and I've effectively signed myself up to take any blame from it. 😬

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Apr 26, 2016

need to investigate #6382 before v6 goes out otherwise we'll be shipping with a broken API

Other option: revert both commits

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Apr 26, 2016

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

@jasnell

This comment has been minimized.

Copy link
Member Author

commented Apr 26, 2016

Ok, closing this now that the Release Proposal PR is open here #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 jasnell closed this Apr 26, 2016

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.