Is it time for a Long Term Support (LTS) version?
bajtos opened this issue · comments
We are seeing growing adoption of LoopBack 4, with many projects already deploying to production. It makes me wonder what kind of stability guarantees are our users expecting from the framework?
At the moment, there is a single release line "Current" where we make all changes (features small and large, bug fixes, security fixes, etc.). Upgrading a LB4-based project to a newer version may require some work on the user side, e.g. when a new TypeScript version is released. This could become a problem when a security vulnerability is fixed and the upgrade from a vulnerable to the fixed version is not trivial.
Is it perhaps time to introduce an LTS release line, where only bug fixes and security patches will be landed? The current LTS policy used for LoopBack 3.x can be found here:
Active LTS
A major LoopBack version (for example, 3.x) enters Active LTS when the next major version is released (for example, 4.0) and stays in Active LTS mode for at least six months.
Once a release enters LTS, no new features may be added to that release. Changes are limited to:
- Bug fixes;
- Security updates;
- Relevant documentation updates;
- Certain performance improvements where the risk of breaking existing applications is minimal;
- Changes that introduce large amount of code churn where the risk of breaking existing applications is low and where the change in question may significantly ease the ability to backport future changes due to the reduction in diff noise. Semver-minor changes are only permitted if required for bug fixes. Semver-major changes are only permitted if required for critical security and bug fixes.
Support for new major Node.js versions may be added if the required changes have a low risk of breaking existing applications.
Maintenance LTS
When a new major version (for example, 4.0) is released, the oldest Active LTS version (for example, 2.x) enters Maintenance LTS mode, where it will stay for as long as the Node.js LTS versions available at release time are maintained by the Node.js project.
Once a release moves into Maintenance LTS mode, only critical bugs, critical security fixes, and documentation updates will be permitted.
Specifically, adding support for new major Node.js versions is not permitted.
I'd like to use this issue to kick-off the initial discussion, where we can learn what our users actually need from the framework. Pinging @strongloop/loopback-maintainers @strongloop/loopback-next @raymondfeng @dhmlau
This sounds like a very good idea. I'm part of a very small team that doesn't have the resources to deal with a breaking change that might get introduced as part of a typical update. Having a stable LTS branch that we could target, along with clear summaries of how a new LTS version affects existing projects, would be appreciated.
Thanks @bajtos for looking into this.
cc'ing a few more people who might be in production:
@marioestradarosa @vvdwivedi @samarpanB @kowsheek
From my point of view it's more important to have feature partity with lb3 then having one or more LTS versions. This will additionally slow down the progress of lb4 feature development.
But... I have to mention, in our projects we are early adopters and update to the latest lb4 version as fast as possible. Doing that, breaking changes are never a problem as they happen in small steps in daily business.
I think LTS has it's benefits. But I think there's some stuff that needs to well-defined:
- How to differentiate LTS and Current release lines on NPM?
Maybe another NPM org such as@loopback-lts/*? - How to differentiate LTS and Current release lines on GitHub?
- How to separate documentation?
Currently, the documentation is updated to work with the latest version of the packages and there's no way to refer back to docs of an older package version. Adding LTS to the mix may make it more messy if not done right.
Since there's multiple packages with independent versioning, we probably can tie the versioning based on the CLI version and publish the supported package versions for each CLI version.
I think we still need LB4 to meet feature parity with LB3 before it can move to LTS. Also, there can be many scenarios where we may require a major upgrade of some of the dependency for performance or some security fix. So, we need to wait until at least we have a level of feature parity and more production deployments over time. That will prove its maturity as well.
Having said that, I do agree we need to be careful about any breaking changes. Having successfully completed multiple projects with LB4, how we deal with upgrades is whenever we start a new project we use the latest version and we upgrade if needed until the project moves to UAT. After that, we stick to that specific version. We haven't faced any major issues so far with this approach.
Recently, we were discussing in several places the implications of dropping support for a major Node.js version (most recently Node.js 8.x) on our version numbers and the LTS policy.
See e.g. loopbackio/loopback-connector#172 and loopbackio/loopback-datasource-juggler#1831.
See also https://twitter.com/matteocollina/status/1245019022271406080
My conclusion is that once we start thinking about LTS for LB4, we need to start dropping support for Node.js version early, so that when the first Node.js major version supported by a LB4 LTS version goes end of life, then the LB4 LTS version goes end of life too. I.e. if LB4 version 2.x supports Node.js 10.x+ , then LB4 2.x must go EOL at the same time (or before) Node.js 10.x goes EOL. Because of the way Module LTS policy works, I think it requires us to create a new semver-major version every autumn, just before a new Node.js LTS version is created, and this new major version must support only that upcoming LTS version.
As a side effect of this policy:
- People who want to run on a major version of Node.js that's older than the current latest LTS version, will have to pick an LTS version of LoopBack too.
- Inside LoopBack codebase, we will be able to adopt the latest Node.js features faster. At the moment, we have to wait until the oldest supported Node.js version goes EOL before we can start adopting newer features. In the new scheme, we will be able to adopt new things as soon as they become available in a Node.js LTS version.
This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.