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.

Sign up for GitHub

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

Jump to bottom

Planning for v6 #5766

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

Planning for v6 #5766

jasnell opened this issue Mar 17, 2016 · 69 comments
Labels
meta Issues and PRs related to the general management of the project.
Milestone
6.0.0

Comments

@jasnell
Copy link
Member

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

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 Issues and PRs related to the general management of the project. label Mar 17, 2016
@Fishrock123
Copy link
Member

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

@chrisdickinson
Copy link
Contributor

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

@Fishrock123
Copy link
Member

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

@Fishrock123
Copy link
Member

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

@jasnell
Copy link
Member Author

jasnell commented Mar 17, 2016

+1 for mid April.

@ofrobots
Copy link
Contributor

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

@jasnell
Copy link
Member Author

jasnell commented Mar 17, 2016

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

@jbergstroem
Copy link
Member

@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
Copy link
Member Author

jasnell 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
Copy link
Contributor

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
Copy link
Member Author

jasnell 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
Copy link
Member

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

@bnoordhuis
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

jasnell 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
Copy link

V8 5.0 is a reasonable target. :)

@jbergstroem jbergstroem mentioned this issue Mar 18, 2016
Closed
@ChALkeR
Copy link
Member

ChALkeR 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
Copy link
Member

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

@cjihrig cjihrig mentioned this issue Mar 21, 2016
Closed
@jasnell
Copy link
Member Author

jasnell 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
Copy link
Member

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

@Trott
Copy link
Member

Trott commented Mar 22, 2016

Added 6.0.0 milestone to #5707

@Fishrock123
Copy link
Member

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

@Martii
Copy link

Martii 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 Remove deprecated Buffer.write(...) #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
Copy link
Member

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

@Martii
Copy link

Martii commented Mar 29, 2016

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

@Martii Martii mentioned this issue Mar 29, 2016
Open
@evanlucas
Copy link
Contributor

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

@jasnell
Copy link
Member Author

jasnell commented Apr 20, 2016

@evanlucas .. added to the list! thanks!

@dlongley
Copy link

Can #5950 get a v6 tag?

@jasnell
Copy link
Member Author

jasnell commented Apr 20, 2016

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

@ofrobots
Copy link
Contributor

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

@piscisaureus
Copy link
Contributor

cc @crandmck

@ChALkeR
Copy link
Member

ChALkeR 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
Copy link

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

@jasnell
Copy link
Member Author

jasnell 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
Copy link
Member

ChALkeR commented Apr 25, 2016

@jasnell That means that the milestone date is off.

@targos
Copy link
Member

targos commented Apr 25, 2016

It's better to be early than late ;)

Merged
@addaleax
Copy link
Member

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
Copy link
Member Author

jasnell 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
Copy link
Member

addaleax commented Apr 25, 2016 •
edited

@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
Copy link
Contributor

ofrobots commented Apr 25, 2016 •
edited

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

@jasnell
Copy link
Member Author

jasnell 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
Copy link
Contributor

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

@addaleax
Copy link
Member 

$ 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
Copy link
Member Author

jasnell 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
Copy link
Contributor

@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
Copy link
Member

@ofrobots Thanks, I’ll take a look.

@addaleax
Copy link
Member

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
Copy link
Member

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

@Fishrock123
Copy link
Member

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
Copy link
Member

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

Other option: revert both commits

@jasnell
Copy link
Member Author

jasnell commented Apr 26, 2016

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

@jasnell
Copy link
Member Author

jasnell 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 as completed Apr 26, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
meta Issues and PRs related to the general management of the project.
Projects
None yet
Milestone
6.0.0
Development

No branches or pull requests