78 lines
3.8 KiB
Markdown
78 lines
3.8 KiB
Markdown
# ADR-007: Independent Application Updates
|
|
|
|
## Status
|
|
|
|
Proposed
|
|
|
|
## 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](ADR-005-package-based-updates.md) provides a natural continuation of this decision.
|
|
|
|
For an independently supplied subsystem that needs its own user-space environment, [ADR-006](ADR-006-container-based-updates.md) 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](ADR-004-full-system-image-updates.md) 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](ADR-010-hybrid-update-strategies.md).
|