build: bump RUSTC_VERSION to 1.88 in github workflows

[joyeecheung]

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
diplomat@0.16.1 requires rustc 1.88
diplomat-runtime@0.15.2 requires rustc 1.88
diplomat_core@0.16.1 requires rustc 1.88
icu_locale_core@2.3.0 requires rustc 1.88
icu_provider@2.3.1 requires rustc 1.88
node_crates@15.5.1 requires rustc 1.88
make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[github-actions]

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

[joyeecheung]

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau@aduh95 can you take a look again?

[richardlau]

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.xPRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

[MikeMcC399]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

[joyeecheung]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

[Renegade334]

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

[joyeecheung]

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

[Renegade334]

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

[joyeecheung]

It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

I think the most benefit of landing it on main is that we reduce the churn of having to float it on canary, otherwise, instead of just adding one commit on main and be done with it, we need to: float the commit in canary, cherry pick it into the >= 15.3 update when the PR is open, and once that PR land, remove it from the canary or it could conflict. Sounds like a lot of churn for little benefit...

[legendecas]

Would you mind updating https://github.com/nodejs/node/blob/main/BUILDING.md?plain=1#L1062-L1063 as well?

[joyeecheung]

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
diplomat@0.16.1 requires rustc 1.88
diplomat-runtime@0.15.2 requires rustc 1.88
diplomat_core@0.16.1 requires rustc 1.88
icu_locale_core@2.3.0 requires rustc 1.88
icu_provider@2.3.1 requires rustc 1.88
node_crates@15.5.1 requires rustc 1.88
make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[github-actions]

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

[joyeecheung]

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau@aduh95 can you take a look again?

[richardlau]

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.xPRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

[MikeMcC399]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

[joyeecheung]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

[Renegade334]

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

[joyeecheung]

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

[Renegade334]

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

[joyeecheung]

It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

I think the most benefit of landing it on main is that we reduce the churn of having to float it on canary, otherwise, instead of just adding one commit on main and be done with it, we need to: float the commit in canary, cherry pick it into the >= 15.3 update when the PR is open, and once that PR land, remove it from the canary or it could conflict. Sounds like a lot of churn for little benefit...

[legendecas]

Would you mind updating https://github.com/nodejs/node/blob/main/BUILDING.md?plain=1#L1062-L1063 as well?

[joyeecheung]

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
diplomat@0.16.1 requires rustc 1.88
diplomat-runtime@0.15.2 requires rustc 1.88
diplomat_core@0.16.1 requires rustc 1.88
icu_locale_core@2.3.0 requires rustc 1.88
icu_provider@2.3.1 requires rustc 1.88
node_crates@15.5.1 requires rustc 1.88
make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[github-actions]

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

[joyeecheung]

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau@aduh95 can you take a look again?

[richardlau]

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.xPRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

[MikeMcC399]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

[joyeecheung]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

[Renegade334]

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

[joyeecheung]

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

[Renegade334]

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

[joyeecheung]

It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

I think the most benefit of landing it on main is that we reduce the churn of having to float it on canary, otherwise, instead of just adding one commit on main and be done with it, we need to: float the commit in canary, cherry pick it into the >= 15.3 update when the PR is open, and once that PR land, remove it from the canary or it could conflict. Sounds like a lot of churn for little benefit...

[legendecas]

Would you mind updating https://github.com/nodejs/node/blob/main/BUILDING.md?plain=1#L1062-L1063 as well?

[joyeecheung]

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
diplomat@0.16.1 requires rustc 1.88
diplomat-runtime@0.15.2 requires rustc 1.88
diplomat_core@0.16.1 requires rustc 1.88
icu_locale_core@2.3.0 requires rustc 1.88
icu_provider@2.3.1 requires rustc 1.88
node_crates@15.5.1 requires rustc 1.88
make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[github-actions]

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

[joyeecheung]

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau@aduh95 can you take a look again?

[richardlau]

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.xPRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

[MikeMcC399]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

[joyeecheung]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

[Renegade334]

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

[joyeecheung]

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

[Renegade334]

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

[joyeecheung]

It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

I think the most benefit of landing it on main is that we reduce the churn of having to float it on canary, otherwise, instead of just adding one commit on main and be done with it, we need to: float the commit in canary, cherry pick it into the >= 15.3 update when the PR is open, and once that PR land, remove it from the canary or it could conflict. Sounds like a lot of churn for little benefit...

[legendecas]

Would you mind updating https://github.com/nodejs/node/blob/main/BUILDING.md?plain=1#L1062-L1063 as well?

[joyeecheung]

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
diplomat@0.16.1 requires rustc 1.88
diplomat-runtime@0.15.2 requires rustc 1.88
diplomat_core@0.16.1 requires rustc 1.88
icu_locale_core@2.3.0 requires rustc 1.88
icu_provider@2.3.1 requires rustc 1.88
node_crates@15.5.1 requires rustc 1.88
make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[github-actions]

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

[joyeecheung]

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau@aduh95 can you take a look again?

[richardlau]

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.xPRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

[MikeMcC399]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

[joyeecheung]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

[Renegade334]

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

[joyeecheung]

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

[Renegade334]

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

[joyeecheung]

It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

I think the most benefit of landing it on main is that we reduce the churn of having to float it on canary, otherwise, instead of just adding one commit on main and be done with it, we need to: float the commit in canary, cherry pick it into the >= 15.3 update when the PR is open, and once that PR land, remove it from the canary or it could conflict. Sounds like a lot of churn for little benefit...

[legendecas]

Would you mind updating https://github.com/nodejs/node/blob/main/BUILDING.md?plain=1#L1062-L1063 as well?

[joyeecheung]

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
diplomat@0.16.1 requires rustc 1.88
diplomat-runtime@0.15.2 requires rustc 1.88
diplomat_core@0.16.1 requires rustc 1.88
icu_locale_core@2.3.0 requires rustc 1.88
icu_provider@2.3.1 requires rustc 1.88
node_crates@15.5.1 requires rustc 1.88
make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[github-actions]

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

[joyeecheung]

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau@aduh95 can you take a look again?

[richardlau]

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.xPRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

[MikeMcC399]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

[joyeecheung]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

[Renegade334]

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

[joyeecheung]

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

[Renegade334]

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

[joyeecheung]

It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

I think the most benefit of landing it on main is that we reduce the churn of having to float it on canary, otherwise, instead of just adding one commit on main and be done with it, we need to: float the commit in canary, cherry pick it into the >= 15.3 update when the PR is open, and once that PR land, remove it from the canary or it could conflict. Sounds like a lot of churn for little benefit...

[legendecas]

Would you mind updating https://github.com/nodejs/node/blob/main/BUILDING.md?plain=1#L1062-L1063 as well?

[joyeecheung]

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
diplomat@0.16.1 requires rustc 1.88
diplomat-runtime@0.15.2 requires rustc 1.88
diplomat_core@0.16.1 requires rustc 1.88
icu_locale_core@2.3.0 requires rustc 1.88
icu_provider@2.3.1 requires rustc 1.88
node_crates@15.5.1 requires rustc 1.88
make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[github-actions]

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

[joyeecheung]

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau@aduh95 can you take a look again?

[richardlau]

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.xPRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

[MikeMcC399]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

[joyeecheung]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

[Renegade334]

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

[joyeecheung]

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

[Renegade334]

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

[joyeecheung]

It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

I think the most benefit of landing it on main is that we reduce the churn of having to float it on canary, otherwise, instead of just adding one commit on main and be done with it, we need to: float the commit in canary, cherry pick it into the >= 15.3 update when the PR is open, and once that PR land, remove it from the canary or it could conflict. Sounds like a lot of churn for little benefit...

[legendecas]

Would you mind updating https://github.com/nodejs/node/blob/main/BUILDING.md?plain=1#L1062-L1063 as well?

[joyeecheung]

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
diplomat@0.16.1 requires rustc 1.88
diplomat-runtime@0.15.2 requires rustc 1.88
diplomat_core@0.16.1 requires rustc 1.88
icu_locale_core@2.3.0 requires rustc 1.88
icu_provider@2.3.1 requires rustc 1.88
node_crates@15.5.1 requires rustc 1.88
make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[github-actions]

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

[joyeecheung]

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau@aduh95 can you take a look again?

[richardlau]

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.xPRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

[MikeMcC399]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

[joyeecheung]

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

[Renegade334]

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

[joyeecheung]

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

[Renegade334]

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

[joyeecheung]

It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

I think the most benefit of landing it on main is that we reduce the churn of having to float it on canary, otherwise, instead of just adding one commit on main and be done with it, we need to: float the commit in canary, cherry pick it into the >= 15.3 update when the PR is open, and once that PR land, remove it from the canary or it could conflict. Sounds like a lot of churn for little benefit...

[legendecas]

Would you mind updating https://github.com/nodejs/node/blob/main/BUILDING.md?plain=1#L1062-L1063 as well?