When running with type majors, it doesn't seem likely that the user is interested in odd-numbered majors except current.

For example, running today with a major range of >=16, the results of deprecated v17 seems irrelevant.

@ljharb If you think this sounds reasonable I could take a stab it at

I've just found that the deprecation warning is displayed in the GitHub Actions workflows for eslint-plugin-import.

• https://github.com/import-js/eslint-plugin-import/actions/runs/3768297080/jobs/6406611863
  

  Warning: The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

I believe the following code in this repository has something to do with it, is that right?

Node 0.6 test suite errors in some compilation step, see https://github.com/SheetJS/sheetjs/runs/4202015198 or https://github.com/es-shims/es5-shim/runs/3885731231 for more info

I noticed that node.yml workflow, for each matrix configuration, the UUT (project) is built with the selected node version, then the test suite is run on the same node runtime. ie:

targets=[v1, v2, v3]
for $target in targets
   build UUT for $target
   test UUT on $target
end

However, in real life, a dev publishes an NPM package built with one node runtime (say v40), and when users include that package in their projects, they build their projects on their own runtime (say v33), and release the product to end users who run it on a variety or runtimes (say v1-99), ie:

build UUT for v40

runtimes=[v1, v2, v3]
for $runtime in runtimes
   test UUT on $runtime
end

Is it valid to assert that if a projects builds on version X and passes the tests on version X for any value of X, then the released package, built on version Y will run correctly on any runtime version from v1-99 ?

Shouldn't the release candidate package be tested against all the supported runtimes?

Thanks