Update 02

adr/ADR-007-independent-application-updates.md

@@ -0,0 +1,77 @@
+# 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).