Review LoopBack's Long Term Support Policy

[achrinza]

Suggestion

Loosely related: #4398

This issue consists of 2 points, both related the Module LTS polcy:

1. Adopt Module LTS on the individual packages

   LoopBack 4 claims to adopt the CloudNative Module LTS Policy. This only applies to the project as a whole, and semver major bumps within the individual packages in the monorepo do not follow the Module LTS policy.

   This may be misleading as users may expect the individual packages to adopt the policy, and not the "blanket" project version 4. This means that we may be bringing unexpected breaking changes to our users. Especially for those who adopt the individual packages and not the LoopBack framework as a whole.

2. Do not drop Node.js versions after EOL

   Current practice is to drop a Node.js version when it EOLs. However, the Module LTS Policy says to only drop when a backwards-incompatible change is necessary to be compatible with the latest version of Node.js:

   Note, there is the possibility that a module could be incompatible with the latest version of Node. In this case, the module should be updated. If breaking changes are required this would consistute a new major version of the module, and this new version would have the same End of Life date as the latest version of Node.

Acceptance criteria

TBD - will be filled by the team.

[dhmlau]

@achrinza, just wanna clarify on the Module LTS policy.
AFAIK, the requirement is: the version of the module cannot go EOL before the Node.js version, that was claimed LTS when the module was still active, goes EOL.

An example might be easier to illustrate that because it took me a while to understand that. :)
Take loopback-connector as an example. The current version is 4.x.

• When Node.js 12 is published, [email protected] is still active. According to Module LTS policy, we need to support [email protected] till Node.js 12 goes end of life.
• If Node.js 14 declared LTS today and [email protected] is still the active version, it means we need to support loopback-connector till Node.js 14 EOL.

As a result, the individual LoopBack modules generally meet (or exceed) the Module LTS policy requirements. Having said that, if you find this is not the case, please do let us know!

[achrinza]

Thanks @dhmlau, for the example.

From my understanding, your example is definitely correct, but I believe it's missing one point. I'd like to take an example from this monorepo as it's what's of concern (loopback-core)

• When Node.js 12 is published, [email protected] is still active. According to Module LTS policy, we need to support [email protected] till Node.js goes EOLs.
• If Node.js 14 declares LTS today, it means we need to support [email protected] until Nodejs 14 EOL.
• However, if no backward-incompatible change is necessary to support Node.js 14, then there is no reason to drop Node.js 14 as the target Node.js version in the Typescript compiler.

It's understandable to drop support for an older version of Node.js to utilise new features, however the Typescript/Babel compiler reduces the amount of times this is necessary.

---

For example, this commit dropped support for Node.js 8 as it's EOL. However, there was no changes to the target build for the Typescript compiler.

Hence, there shouldn't have been a need to drop support for Node.js 8 yet - not until a Typescript release breaks compatibility with that version of Node.js. or we need to utilise a new Typescript feature that requires us to increase the target property in tsconfig.common.json.

[achrinza]

There's also the concern that we're adopting Module LTS for the LoopBack framework as a whole, and not on the individual packages which may adoption of individual LoopBack packages (e.g. @loopback/context) difficult as they may have an unpredictable support schedule when semver major releases occur.