Repository navigation
Evaluate compatibility per RFC 0017 and the os list per RFC 0031 #39
Description
ModVersionMetadata carries GameMinRevision, GameMaxRevision and Os.
RFC 0017 defines four states:
| State | Condition |
|---|---|
| Unknown | No usable lower bound. |
| Incompatible | The installed revision is below the lower bound. |
| Compatible | The upper bound is absent, or the installed revision is at or below it. |
| Untested | The installed revision is above a stated upper bound. |
Incompatible is the only state that blocks.
This classifies only; what a client does with Untested and Unknown is a UI decision and not part of this issue.
Shape, in Borea.Core:
-
enum GameCompatibility { Compatible, Untested, Incompatible, Unknown } -
Evaluate(int? minRevision, int? maxRevision, GameVersion installed), plus an overload taking aModVersionMetadata. - Compare
installed.Revisionagainst the bound integers directly.
On Unknown: ModVersionMetadata requires gameMin and a non-nullable GameMinRevision, so the release overload can never return Unknown and there is no "no bounds at all" case for a release. That is expected, not a gap to fix here. Unknown exists for the listing side, where SpaceDockModRepository maps an unparseable game version to GameMin = "unknown". The nullable parameter is what makes the state reachable.
The os list, from the same [compatibility] table. RFC 0031: "A platform outside the stated os list warns and lets the user proceed: the list states what the author knows works, not everything that can." Advisory, never blocking.
- The vocabulary is
windows,linux,macos; the RFC adds "New values arrive by RFC". - The check takes the target platform as a parameter and never reads the running OS, so it stays testable on the three-OS CI matrix.
- Absent means no known restriction. Treat an empty list the same way, and say in a comment that this is our choice: the RFC defines only absent, and the domain deliberately keeps empty distinct from absent.
- Compare case-insensitively as client leniency; the RFC states no comparison rule for os.
- An unrecognised value must not make the list unusable and must not be silently dropped: keep evaluating the recognised entries and report the unrecognised ones, so a caller can say the listing knows a platform this build does not.
- Give the
Unknownmember a doc comment saying it means no usable compatibility data, becauseModStatus.UnknownandReleaseStatus.Unknownalready use the name for "a value this client version does not know".
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity