Repository navigation
Is it time for a Long Term Support (LTS) version? #4398
Description
Activity
- changed the title
[-]Long Term Support (LTS) version[/-][+]Is it time for a Long Term Support (LTS) version?[/+]on Jan 9, 2020 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 @kowsheekFrom my point of view it's more important to have feature partity with
lb3then having one or more LTS versions. This will additionally slow down the progress oflb4feature development.But... I have to mention, in our projects we are early adopters and update to the latest
lb4version as fast as possible. Doing that, breaking changes are never a problem as they happen in small steps in daily business.Reacted by Matteo Padovano, Rifa Achrinza, Aidan Harbison and Zakaria MansouriI 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.
- How to differentiate LTS and Current release lines on NPM?
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.
Reacted by Matteo PadovanoRecently, 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.
Reacted by Joe DevlinThis 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
CODEOWNERSfile at the top-level of this repository. This issue will be closed within 30 days of being stale.- locked and limited conversation to collaborators
on Mar 11, 2021
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:
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