Review requested:

• @nodejs/actions
• @nodejs/performance
• @nodejs/security-wg
• @nodejs/startup
• @nodejs/tsc

@aduh95 that's fine, but can you help me understand why main would affect v24, which this commit wouldn't land on at all?

Commits make their way to LTS lines by being first released onto a Current release for at least two weeks, and Current releases get their commits from main; so landing this before 24.x is in maintenance would add unnecessary maintenance burden, as already discussed in #57617.

Unfortunately the previous discussion, and this one, didn't make it clear to me why this is a burden. I'm aware that commits will land on main before being backported to v24, but the things this PR touches are highly unlikely to conflict with anything destined for v24 or older, so I'm unclear on what maintenance burden there would be.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.95%. Comparing base (6428e2e) to head (ef9eeb1).
⚠️ Report is 1 commits behind head on main.

@@           Coverage Diff           @@
##             main   #57763   +/-   ##
=======================================
  Coverage   89.95%   89.95%           
=======================================
  Files         667      667           
  Lines      196813   196813           
  Branches    38425    38430    +5     
=======================================
+ Hits       177038   177039    +1     
+ Misses      12200    12193    -7     
- Partials     7575     7581    +6     

see 30 files with indirect coverage changes

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

There's no point in releasing in a Current line that doesn't have the feature. I don't believe it will be more difficult to maintain if the code only lives on <=v24.x. We'll just need to change automation to open the update PR against v24.x-staging instead of main.

I don't believe it will be more difficult to maintain if the code only lives on <=v24.x. We'll just need to change automation to open the update PR against v24.x-staging instead of main.

Of course it would be, PR targeting main can be landed by any collaborator (or even triaggers using CQ), PRs targeting a staging branch fall under the responsibility of the releaser.

There's no point in releasing in a Current line that doesn't have the feature

For end users, sure. For us maintainers, the point is to keep using the existing process and minimize manual interventions.

I think I understand the issue - because of the policy that anything destined for Current or LTS has to sit on main for 2 weeks, commits updating corepack have to land on main, which means this PR can't land on main.

Either blocking this PR until 24 is in maintenance would work, or, altering the policy so that some kinds of commits don't have to hit main before landing in Current/LTS.

To clarify, the policy is not blocking, we could still manage pushing updates to specific branches, the Release WG would likely won't see any problem with that. However, as explained in my previous comment, it would make Corepack maintenance harder / give more work to the releasers, so I'm against it.