Long-term support

Overview

LoopBack adheres to semantic versioning conventions and implements Module LTS policy.

The project maintains:

• A Current version where most of the development occurs.
• An Active LTS (Long-Term Support) version that does not add new features but gets bug fixes.
• One or more Maintenance LTS versions that receive only critical bug fixes.

Below is the LTS schedule on the LoopBack versions:

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:

1. Bug fixes;

2. Security updates;

3. Relevant documentation updates;

4. Certain performance improvements where the risk of breaking existing applications is minimal;

5. 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.

Information for LoopBack 3 users

LoopBack version 3 reached end of life at the end of 2020. We understand some users might still be using LoopBack 3 and have questions about the implications of running LoopBack 3 in production.

• Security vulnerabilities: Critical security fixes will be applied as needed by IBM API Connect

• New features: No features will be accepted.

• Bugs: We are not going to actively fix any bugs reported by the community users. For critical bugs, maintainers will review and assess the risks of community-submitted PRs. If you’re planning to submit a fix, it’s the best to open a GitHub issue to discuss with the maintainers before proceeding.

Please note that the December 2020 end-of-life date is applicable to community support. If you are using LoopBack as part of the IBM API Connect v5 or v2018 product, check with the product announcement for its end-of-support schedule.

We strongly encourage all our users to stop using LB3 as soon as they can.

What should I do if I’m still using LoopBack 3?

If you already have LoopBack 3 applications running in production, it is highly recommended for you to review the Understanding the differences between LoopBack 3 and LoopBack 4 page as mentioned in one of our older blog posts. There is also the migration guide helping you to migrate your LoopBack 3 applications incrementally.

What if I cannot migrate to LoopBack 4 any time soon?

Your LoopBack 3 applications will continue to work even after LoopBack 3 reaches end of life. There will be very minimal, if any, changes going into the codebase. In the case of addressing security vulnerabilities, you might need to fork the corresponding GitHub repos and apply security fixes. See this blog for the list of Node.js packages reaching end-of-life along with loopback repo.

The biggest risk of running on LB3 lies in security vulnerabilities that may be discovered in the future, as they are unlikely to be fixed. LB3 is also depending on old versions of many packages, so even when a dependency fixes a vulnerability in the latest version, it would require a lot of effort to upgrade LB3 to that new version. Such upgrade is likely to introduce breaking changes for LoopBack consumers, which makes it even more tricky.