Task 3 — System Version Compatibility

Objective

Design a compatibility resolver for three dependent software systems.

The systems are:

S1
S2
S3

Their dependency chain is:

S1
 ↓
S2
 ↓
S3

In other words:

S2 depends on S1
S3 depends on S2

The resolver must determine valid installation, update, and upgrade paths while preserving compatibility and dependency requirements.

Published Version Data

The available production versions are represented in three columns:

S1      | S2       | S3
--------------------------------
1.0.0   | 1.0.0    | 1.0.0
1.1.0   | 1.1.0    | -----
1.1.1   | -----    | 1.1.0
-----   | 1.2.0    | 1.1.1
1.2.0   | 1.3.0    | -----
1.3.0   | -----    | 1.2.0
1.3.1   | 1.4.0    | 1.2.1
-----   | 1.4.1    | 1.2.2
1.4.0   | 1.5.0    | -----
-----   | -----    | 1.3.0
1.5.0   | 1.6.0    | 1.3.1
1.5.1   | 1.6.1    | -----
1.5.2   | -----    | 1.4.0
-----   | 1.7.0    | 1.4.1
1.6.0   | 1.7.1    | -----
1.6.1   | 1.7.2    | 1.5.0
-----   | -----    | -----
1.7.0   | 1.8.0    | 1.6.0
1.7.1   | 1.8.1    | 1.6.1
1.7.2   | -----    | 1.6.2
-----   | 1.9.0    | 1.6.3
1.8.0   | 1.9.1    | -----
1.8.1   | 1.9.2    | 1.7.0
-----   | 1.9.3    | 1.7.1
1.9.0   | -----    | 1.7.2
1.9.1   | 1.10.0   | 1.7.3

A missing version is represented by:

-----

Compatibility Rule

Versions are compatible when they belong to the corresponding update generation.

The original task provides the following explicit example.

The second generation of S1 contains:

1.2.0
1.3.0
1.3.1

The compatible second-generation S2 versions are:

1.2.0
1.3.0

The compatible second-generation S3 versions are:

1.1.0
1.1.1

Therefore compatibility must be modeled by generation rather than by requiring identical semantic-version numbers across systems.

Important Source Limitation

The original task explicitly describes the second generation as an example but does not enumerate the complete generation boundaries for every version in the table.

The implementation must therefore model those generation relationships explicitly as part of the exercise.

Do not assume that versions are compatible merely because:

major versions match

or because:

minor version numbers are numerically similar

Compatibility is defined by the generation mapping.

Dependencies

The dependency chain must never be broken.

Installing S2

S2 cannot be installed unless a compatible S1 is already installed or included in the requested operation.

Invalid example:

Installed:
S1 = none

Request:
Install S2

Result:

dependency conflict

Installing S3

S3 requires a compatible S2.

Since S2 itself depends on S1, a valid S3 installation ultimately requires the full compatible dependency chain.

Update and Upgrade

The resolver must distinguish between operations requested against the client’s current infrastructure.

A client may request:

• installation
• update
• upgrade
• latest compatible version
• latest compatible dependency chain

The exact internal representation is left to the developer.

Suggested Models

A version can be represented as:

type SystemVersion struct {
    System     string
    Version    string
    Generation int
}

An installed infrastructure state can be represented as:

type Infrastructure struct {
    S1 string
    S2 string
    S3 string
}

A request can be modeled as:

type CompatibilityRequest struct {
    ClientID string
    Current  Infrastructure
    Action   string
    Target   Infrastructure
}

A response can be modeled as:

type CompatibilityResponse struct {
    Valid       bool
    Current     Infrastructure
    Recommended Infrastructure
    Conflicts   []string
    Actions     []string
}

These types are suggestions.

The original task explicitly requires creating a custom client-side request and server-side response, so the exact representation is part of the exercise.

Client Scenario 1 — Alex

Alex currently has:

S1 = 1.5.1

He wants to install:

the newest S2 version compatible with his S1

The resolver must determine the newest compatible S2 while preserving the dependency relationship.

Client Scenario 2 — Ben

Ben currently has:

S1 = 1.7.2

He wants to install:

the newest compatible S2
the newest compatible S3

The resolver must determine a compatible chain:

S1 -> S2 -> S3

Client Scenario 3 — Lana

Lana currently has:

S1 = 1.5.1
S2 = 1.7.0
S3 = 1.4.0

She wants to update her current:

S2
S3

The resolver must first validate that the current configuration is compatible and then determine valid updates.

Client Scenario 4 — David

David currently has:

S1 = 1.8.1
S2 = 1.9.3
S3 = 1.6.1

He wants to update:

S2
S3

The resolver must detect any existing compatibility conflict before recommending changes.

Client Scenario 5 — Naomi

Naomi currently has:

S1 = 1.8.0
S2 = 1.9.1
S3 = 1.6.1

She wants updates for all three systems.

The resolver must determine the newest valid compatible infrastructure according to the generation rules.

Client Scenario 6 — Emma

Emma currently has:

S1 = 1.6.0

She wants to:

1. upgrade S1 to the newest version of the next S1 generation
2. install the newest compatible S2
3. install the newest compatible S3

The complete recommended chain must remain compatible.

Client Scenario 7 — Helen

Helen has none of the systems installed.

She wants:

the latest compatible versions of all three systems

The resolver must select a complete valid dependency chain.

Client Scenario 8 — Nolan

Nolan is a new user.

He specifically wants:

S3 = 1.6.3

The resolver must work backward through the dependency chain and determine:

latest compatible S2
latest compatible S1

for that requested S3 version.

Conflict Detection

The resolver must report a conflict when:

• an installed combination is incompatible
• a requested version is incompatible with an existing dependency
• a dependency required by a requested system is missing
• no compatible version exists
• an operation would break the dependency chain

A conflict response should explain the reason rather than return only:

false

Request and Response Requirement

The original task explicitly requires:

Create custom client side request and server side response.

Therefore the solution should expose a clear request model and a structured result model.

Avoid returning unrelated values through loosely typed structures.

Validation

At minimum, validate:

• system identifiers
• version existence
• requested action
• dependency availability
• generation compatibility
• current infrastructure consistency

Implementation Notes

This task is primarily about modeling compatibility relationships.

A useful separation is:

version registry
      ↓
generation mapping
      ↓
dependency graph
      ↓
current-state validation
      ↓
request resolution
      ↓
recommended state

Do not hard-code separate logic for Alex, Ben, Lana, David, Naomi, Emma, Helen, and Nolan.

All scenarios should be resolved by the same generic compatibility engine.