ADR-007: Independent Application Updates

Context

An embedded Linux device may contain applications that change more frequently than its operating system. Releasing a complete system image for every application change can tie unrelated work to the same release schedule.

For example, a diagnostics service may need a new feature while the communication service and system platform remain unchanged.

This educational example considers applications maintained on a stable, versioned platform. It asks whether an application should have its own release lifecycle. The choice of delivery format follows that decision.

Decision

Release an application independently when it has a distinct maintenance need and can operate through stable interfaces to the platform and other components.

Define the supported platform and data formats for each application release. Keep tightly coupled components in the same release unit when they cannot reasonably evolve independently.

Decision Drivers

Application changes occur more frequently than platform changes.
A fix should be delivered without releasing unrelated software.
Application boundaries and interfaces can remain stable.
The team can validate and maintain the supported application/platform combinations.

Consequences

Positive

An application can be released without rebuilding the complete device software.
Individual features can evolve at their own pace.
A smaller release unit can reduce the amount of software delivered for a change.
Maintenance responsibility can follow the application's boundaries.

Negative

The system version alone no longer identifies all installed software.
Supported platform and application combinations must be tracked.
Application activation and recovery need their own handling.
Shared data or unstable interfaces can undermine the intended independence.

Special Considerations

Independence Before Packaging

A separate process or directory does not necessarily form an independent application. If diagnostics requires simultaneous changes to the communication service for every release, their delivery schedules remain coupled.

Stable interfaces make separate releases practical. Packaging expresses that boundary; it does not create it.

Selecting a Delivery Format

For components that depend on a known system platform, the package model in ADR-005 provides a natural continuation of this decision.

For an independently supplied subsystem that needs its own user-space environment, ADR-006 explores container delivery.

An application is therefore an update target, not a competing format alongside packages and containers.

Activation and Application Data

An application release may become active after a service restart rather than a device reboot. The acceptable interruption depends on the application's role.

Keeping a previous application version gives a possible return path. That path must also account for the configuration and data the application reads. Replacing executable files alone does not reverse a data-format change.

Applicability

This approach fits a device whose applications genuinely evolve separately on a platform with a defined compatibility boundary.

Prefer a shared release unit when components repeatedly need coordinated changes or when the product is intentionally validated and maintained as one complete software version.

Alternatives Considered

Full-system image updates keep the software stack under one release lifecycle.
Grouping related applications into one release reduces coordination between tightly coupled components.

A design that combines separate application releases with platform and data updates is explored in ADR-010.

3.8 KiB Raw Blame History