eLabFTW release schedule

eLabFTW follows a frequent release model: new minor versions are published regularly, and patch releases are issued when needed. We do not provide Long Term Support (LTS) versions.

This post explains why.

Release schedules are a tradeoff

Software projects adopt many different release strategies. Some publish major versions on a fixed schedule. Some release continuously. Others have long gaps between releases.

No single approach is objectively best. Each model comes with tradeoffs between stability, maintenance effort, development speed, and security response. The right choice depends on the nature of the software and the resources available to maintain it.

Maintenance matters as much as release frequency

Releasing a version is only part of the job. Every supported version must also be maintained over time.

That means tracking bugs, reviewing security reports, updating dependencies, rebuilding images, and shipping fixes. In some projects, supported versions are maintained for many years. While that can be valuable for administrators, it also creates a significant burden for maintainers, especially when fixes need to be backported to older codebases.

Why eLabFTW releases frequently

eLabFTW is a complex application that depends on many components. Because of that, regular releases are necessary.

We publish minor releases every few weeks and patch releases when necessary. We understand that some system administrators would prefer a slower cadence and longer periods without upgrades. That is a valid operational preference.

However, eLabFTW is not designed around that model. Keeping the software secure and reliable requires us to update dependencies, rebuild images, and ship improvements regularly.

The reality of security and dependency maintenance

As open source maintainers, we receive a high volume of security reports every week. Many of them concern development dependencies or issues that do not affect production systems directly, but each report still needs to be reviewed.

On top of that, there are vulnerabilities in container images, runtime dependencies, and sometimes in the application itself. Staying current requires continuous maintenance work: checking reports, updating components, rebuilding images, tagging versions, and publishing releases.

This is one of the main reasons we cannot reasonably support many older versions in parallel.

Why eLabFTW does not offer LTS releases

LTS stands for Long Term Support: a version that continues to receive bug fixes and security updates for an extended period.

eLabFTW does not offer LTS releases because we do not have the resources to maintain old branches over the long term. Backporting fixes to older versions can be difficult and time-consuming, especially when the current codebase, tooling, and deployment process have already moved forward.

Maintaining separate long-lived branches would slow down development and reduce our ability to respond quickly to security and maintenance issues in the current version.

What this means for administrators

If you run eLabFTW, you should expect to update it regularly.

Our goal is to keep upgrades manageable and predictable, but the recommended approach is to stay reasonably close to the current release rather than remain on an old version for a long time.

If your environment requires multi-year version stability with backported fixes and minimal change over time, eLabFTW may not be the right fit operationally.

In short

eLabFTW uses a frequent release cadence because that is the most sustainable way for us to maintain the project, respond to security issues, and keep the software healthy.

That choice means there are no LTS versions, and it means administrators should plan for regular updates as part of operating eLabFTW.

• elabftw
• meta