Use case | Supporting both stability and innovation with LTS and feature releases

Organizations that deploy Digi devices often operate in very different environments, even when using the same underlying platform. For example, ACME Manufacturing uses Digi devices to support factory operations that evolve frequently and benefit from rapid access to new features, while Northwind Utilities relies on Digi devices for critical infrastructure where stability, predictability, and regulatory compliance are paramount. Although both organizations deploy devices using the same DAL OS LTS firmware release baseline, their operational requirements lead them to follow different firmware update paths.

The following example illustrates how the Digi LTS and feature release model supports both scenarios without forcing change into deployed systems.

Stage	ACME Manufacturing (feature driven)	Northwind Utilities (stability-driven)
Initial deployment	Devices are deployed using Release 1 LTS, which includes Feature A (version 1).
LTS baseline behavior	Feature set is frozen; Feature A behaves consistently and predictably.
New feature availability	Digi releases Feature A (version 2) in a non-LTS firmware release.
Customer action	ACME upgrades to the non-LTS release after testing and validation.	Northwind remains on Release 1 LTS.
Updates applied	Full non-LTS firmware update including new feature functionality.	LTS patch updates containing security and critical bug fixes only.
Feature A behavior	Feature A is updated to version 2 with new functionality.	Feature A remains at version 1 with unchanged behavior.
System behavior	Behavior changes are introduced intentionally as part of the upgrade.	No behavioral changes are introduced.
Operational outcome	ACME gains immediate access to new capabilities.	Northwind maintains validated, certified, and predictable operation.

Result for ACME Manufacturing

By updating to a non-LTS release, ACME Manufacturing adopts new functionality introduced in Feature A (version 2). The resulting behavior changes are expected and controlled, since the update is performed deliberately after testing and validation.

Result for Northwind Utilities

By remaining on the LTS release and applying only LTS patch updates, Northwind Utilities preserves existing system behavior while continuing to receive security and critical stability fixes.

What Happens Next

As non-LTS releases continue to introduce new functionality, features are validated through real-world use. When Digi publishes a new LTS release, validated features may be incorporated into the new baseline, allowing organizations to plan an upgrade when it aligns with their operational and validation requirements.

Key Takeaway

This example demonstrates how Digi’s LTS release model separates long-term stability from feature evolution. LTS releases provide a predictable maintenance baseline, while non-LTS releases enable the introduction and validation of new functionality. By controlling what changes within an LTS release and allowing customers to adopt new behavior only through deliberate upgrades, Digi ensures deployed systems remain stable, secure, and manageable over time.