Tensions in Practice: Partial upgrades must pass through a version pair¶
Two coupled modules being upgraded
Imagine modules A and B, each available in versions 1 and 2. The declared compatibility rule allows A1+B1, A2+B1 and A2+B2, but not A1+B2. Both the old and new complete systems work. Compare stopping service to replace both together with a staged upgrade that keeps a compatible pair running. The order of the partial changes matters even though the destination is the same.
Avoid mixed-version operation
Make a coordinated change without operating a transitional pair.
Preserve service during change
Use an allowed intermediate pair while upgrading one module at a time.
Why these aims pull against each other
A staged upgrade creates an intermediate running state that a complete replacement can avoid. Its compatibility must be established independently of the two endpoint systems.
Choose an arrangement to see what changes and what remains difficult.
Compare the same rows across alternatives. Cells state explicit toy quantities, membership or permissions; colors do not supply additional meaning.
What this choice protects
What it costs
When it fits
Compare the arrangements
Replace together
Stop service, replace A and B during the same outage, then start A2+B2. No mixed pair runs.
| Running pair | Valid pair? | Action | |
|---|---|---|---|
| Start | A1 + B1 | Yes | Keep running |
| Change | None | Not running | Replace both |
| Finish | A2 + B2 | Yes | Resume service |
- What it protects
- Avoids supporting and operating a mixed-version intermediate state.
- What it costs
- Service is unavailable during the coordinated replacement and both changes must be ready together.
- When it fits
- Plausible when an outage is acceptable and simultaneous replacement can be coordinated.
Illustration note: This is an editorial, deliberately bounded illustration. Its stated rules and any numbers are invented, not observations, recommended settings, or predictions.
Upgrade A first
Move from A1+B1 to A2+B1, then to A2+B2. Updating B first would instead enter the forbidden A1+B2 state.
| Running pair | Valid pair? | Action | |
|---|---|---|---|
| Start | A1 + B1 | Yes | Keep running |
| Change | A2 + B1 | Yes | Upgrade A |
| Finish | A2 + B2 | Yes | Upgrade B |
- What it protects
- The declared compatibility relation permits service through this sequence.
- What it costs
- A2 must retain B1 compatibility during the transition; the sequence requires version-aware coordination and testing.
- When it fits
- Plausible when the intermediate pair is genuinely supported and maintaining service warrants this extra work.
Illustration note: This is an editorial, deliberately bounded illustration. Its stated rules and any numbers are invented, not observations, recommended settings, or predictions.
What this illustration does—and does not—establish
The source establishes the structural tension; the concrete alternatives and their conditional costs are editorial synthesis. No arrangement is a universal recommendation.
- Compatibility is invented and explicitly stipulated, not inferred from version numbers. Neither diagram proves a real upgrade safe.
- A replacement operation may itself require interruption even when the running pairs are compatible; seamless switching is an additional assumption here.
- This is a two-module route, not a quorum-consensus or data-migration protocol.
Source entries
Design for Lifecycle Adaptability
Design for lifecycle adaptability Staged implementation and system integration supplies the local tension. The setting, alternative arrangements, and stipulated consequences are editorial applications.
Staged implementation and system integration
Lifecycle adaptability often involves staged implementation (replace component A, then component B, then component C over time, rather than replacing the entire system at once). However, staged implementation can create version-mismatches and integration problems: component A expects version 2 interfaces, component C is still version 1, integration testing becomes complex.