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

Preparation for Node.js 12 #417

Closed
5 of 6 tasks
BethGriggs opened this issue Feb 18, 2019 · 12 comments
Closed
5 of 6 tasks

Preparation for Node.js 12 #417

BethGriggs opened this issue Feb 18, 2019 · 12 comments
Assignees

Comments

@BethGriggs
Copy link
Member

BethGriggs commented Feb 18, 2019

Issue for tracking the progress of Node 12. The current checklist is based on @jasnell's guide for major releases - nodejs/node#25497.

  • Cut branches v12.x, v12.x-staging and keep in sync with master
  • Create v12.x-proposal branch that tracks v12.x - ETA February 23rd 2019
  • Create test builds from v12.x-proposal - ETA March 12th 2019
  • Start cherry-picking commits manually - ETA March 23rd 2019
  • Start creating RCs from v12.x-proposal - 1 per week from March 23rd 2019
  • Release - ETA April 23rd 2019

SemVer-Major cutoff - March 23rd 2019

@BethGriggs BethGriggs self-assigned this Feb 18, 2019
@mhdawson
Copy link
Member

We should probably add a step for adding the release to the data captured on benchmarking.nodejs.org

@BethGriggs
Copy link
Member Author

First test build - https://nodejs.org/download/test/v12.0.0-test1482547441/

@vsemozhetbyt
Copy link

Sorry, if this is a wrong place to ask.

We remove experimental warnings for fs and dns promisified API (see nodejs/node#26581 and nodejs/node#26592). Is it worth to also remove such warnings for readable[Symbol.asyncIterator]() and rl[Symbol.asyncIterator]()?

@rvagg
Copy link
Member

rvagg commented Mar 12, 2019

it's critical that @nodejs/build comes up with a final "support platforms" list as well as the base platforms for compiling releases, I don't believe we have this written up in a single place but there are some major changes that we need to lock in

@richardlau
Copy link
Member

it's critical that @nodejs/build comes up with a final "support platforms" list as well as the base platforms for compiling releases, I don't believe we have this written up in a single place but there are some major changes that we need to lock in

That really sounds like something that should be on the agenda for the Build WG meetings (next one being later today: nodejs/build#1715).

@rvagg
Copy link
Member

rvagg commented Mar 12, 2019

Assuming we need to bump NODE_MODULE_VERSION, we have to make sure we don't just straight increment, we have Electron making a claim on the next two numbers (69 and 70) so we just bump past that. See nodejs/TSC#651 (comment) and the current "registry" (WIP) @ nodejs/node#24114

@Trott
Copy link
Member

Trott commented Mar 25, 2019

@BethGriggs Is the tsc-agenda label here for visibility (that is, to make sure the TSC knows about this issue) or is there something the TSC needs to actually do or decide here?

@BethGriggs
Copy link
Member Author

BethGriggs commented Mar 25, 2019

@Trott, yes, it was just for awareness

@Trott
Copy link
Member

Trott commented Mar 28, 2019

Mentioned at the TSC meeting today. Removing the tsc-agenda label. Feel free to re-add it if there's more for the TSC to do.

@rvagg
Copy link
Member

rvagg commented Apr 16, 2019

Working through an infrastructure checklist @ nodejs/build#1768, it's not very healthy this close to release unfortunately.

@BethGriggs
Copy link
Member Author

Do the symlinks for https://nodejs.org/dist/latest-vN.x/ get created automatically? Or is that something @nodejs/build typically handles?

@jasnell
Copy link
Member

jasnell commented Apr 22, 2019

That happens automatically

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants