You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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).
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
@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?
Activity
mhdawson commentedon Feb 20, 2019
We should probably add a step for adding the release to the data captured on benchmarking.nodejs.org
BethGriggs commentedon Mar 11, 2019
First test build - https://nodejs.org/download/test/v12.0.0-test1482547441/
vsemozhetbyt commentedon Mar 11, 2019
Sorry, if this is a wrong place to ask.
We remove experimental warnings for
fsanddnspromisified API (see nodejs/node#26581 and nodejs/node#26592). Is it worth to also remove such warnings forreadable[Symbol.asyncIterator]()andrl[Symbol.asyncIterator]()?rvagg commentedon 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 commentedon Mar 12, 2019
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 commentedon 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#24114Trott commentedon Mar 25, 2019
@BethGriggs Is the
tsc-agendalabel 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 commentedon Mar 25, 2019
@Trott, yes, it was just for awareness
Trott commentedon Mar 28, 2019
Mentioned at the TSC meeting today. Removing the
tsc-agendalabel. Feel free to re-add it if there's more for the TSC to do.rvagg commentedon Apr 16, 2019
Working through an infrastructure checklist @ nodejs/build#1768, it's not very healthy this close to release unfortunately.
BethGriggs commentedon Apr 22, 2019
Do the symlinks for https://nodejs.org/dist/latest-vN.x/ get created automatically? Or is that something @nodejs/build typically handles?
jasnell commentedon Apr 22, 2019
That happens automatically