Use latest LTS release for development

[Gudahtt]

We now use the LTS release for development rather than a fixed version. This makes it clear that we expect libraries to be updated to be compatible with the latest LTS release, and reduces the frequency of README/nvmrc updates needed.

Examples

No examples yet

[MajorLift]

How should we handle the engines.node field in package.json (currently ">=16.0.0") and the corresponding entry in constraints.pro?

% The package must specify a minimum Node version of 16.
gen_enforced_field(WorkspaceCwd, 'engines.node', '>=16.0.0')

[Mrtenz]

How should we handle the engines.node field in package.json (currently ">=16.0.0") and the corresponding entry in constraints.pro?

% The package must specify a minimum Node version of 16.
gen_enforced_field(WorkspaceCwd, 'engines.node', '>=16.0.0')

The .nvmrc file is only used for development. The development Node.js version doesn't have to be the minimum Node.js version we support, as long as the minimum Node.js version is tested properly in CI.

[Gudahtt]

The engines field specifies the range of compatible Node.js versions, whereas the .nvmrc file is for the recommended version for contributors to use.

Previously we had kept nvmrc pointed at the minimum compatible version, but this PR is an intentional departure from that. It's fairly common in other libraries to use a higher .nvmrc than minimum already. My thinking was that we can rely upon CI to highlight version-specific incompatibilities, as CI should test at least one version of each supported major Node.js version.

[MajorLift]

Relying on CI to make sure nothing breaks on all supported node versions makes perfect sense. Thanks for the clarification.