Use Case

As a... Node driver engineer
I want... to make sure that Node.js version-sensitive tests run on each officially supported major version and version-insensitive tests only run on latest compatible stable Node.js major version
So that... I have full test coverage against our officially supported Node.js major versions but otherwise keep the tooling ahead of EOL to minimize the risk of EOL-tooling related failures.

User Impact

• Minimize risk of Node.js version-related regressions (this is fairly low as is, but not zero)
• Faster development time when tooling doesn't break from under us

Dependencies

• We should do this after the bindings are moved into the driver (NODE-5283)

Unknowns

• How thorough do we want to be with the in-between major versions? We may be able to get away with testing lowest supported and highest supported versions for most configs and only run the full set of Node versions for the main integration suite along with a selection of identified high risk areas.

Acceptance Criteria

Implementation Requirements

• For each library we maintain, for each CI task that we currently run in evergreen or GH:
  • Determine whether or not the Node.js version compatibility should be in the scope of the test suite's intended purpose
  • If the Node.js version should be in scope, briefly summarize why and what the highest areas of concern are; and, considering the overall risk of Node.js version-related regression, recommend whether we should be testing all versions or just min/max for this test suite
• Review the recommendations with the team
• Adjust the CI to reflect the agreed upon approach

Testing Requirements

• N/A - Investigation & CI work

Documentation Requirements

• N/A

Follow Up Requirements

• N/A

Dev note:

• The server platform support matrix informs the minimum Node.js versions we need to continue to support
• See Guidelines around Evergreen distros