Skip to content

Compatibility

Fievetl edited this page Jul 4, 2026 · 4 revisions

Compatibility

Verdict table

Empirical results from the version compatibility sweep (.github/workflows/compat.yml), which builds Atlas against each game version's own dlls and runs the full E2E suite on a real embedded server:

Version Status Notes
1.22.3 Compatible All E2E scenarios green
1.22.2 Compatible All E2E scenarios green, tested on every push
1.22.1 Compatible All E2E scenarios green, tested on every push
1.22.0 Compatible All E2E scenarios green, tested on every push
1.21.7 Incompatible (API) Build fails: the server exit lifecycle Atlas hooks (EnumExitMode, GameExitState, ServerMain.exitState) does not exist before 1.22
1.20.12 Incompatible (API) Build fails: same missing exit lifecycle API as 1.21.7
1.19.8 Incompatible (API) Build fails: same as above, plus ServerMain.PreLaunch and the ServerProgramArgs boot signature differ
1.18.15 Incompatible (API) Build fails: same as above, plus Vintagestory.API.Common.Func collides with System.Func

Each row is the latest patch of its minor available on the stable CDN; 1.18.0 through 1.18.7 predate the game's .NET migration and ship under a different server archive entirely. The supported floor is therefore Vintage Story 1.22.0. The table reflects the sweep run of 2026-07-03.

What "incompatible (API)" means

The sweep classifies a version as incompatible (API) specifically when the build step itself fails against that version's VintagestoryAPI.dll and VintagestoryLib.dll (as opposed to a build that succeeds but an E2E test that fails, which is classified partial). For every version below 1.22.0, the failure is the same root cause: Atlas's boot path uses the exit-lifecycle API introduced in Vintage Story 1.22 (EnumExitMode, GameExitState, ServerMain.exitState), which does not exist in earlier versions. Supporting 1.21.x and below would mean isolating those calls behind a version-adaptive shim (reflection or compile-time abstraction) rather than a rewrite. See issue #15 for the open question of whether demand justifies that maintenance cost.

How the weekly sweep works

.github/workflows/compat.yml runs on a schedule (cron: "0 6 * * 1", every Monday) across a matrix of Vintage Story versions. For each version:

  1. Download and cache that version's Linux server archive from the Vintage Story CDN.
  2. dotnet build Atlas.slnx -c Release against that version's dlls (continue-on-error: true, so a failure here does not abort the workflow, only that version's leg).
  3. If the build succeeded, run Atlas.Engine.Tests and Sample.Scenarios, both filtered to Category=E2E (also continue-on-error: true).
  4. Compute a verdict per version: compatible (build and both E2E suites passed), incompatible (API) (build failed), or partial (build succeeded but at least one E2E suite failed), with a short note naming which suite failed for partial.
  5. An aggregate job collects every version's verdict artifact and renders a consolidated table into the workflow's step summary.

Running it manually

Trigger a sweep on demand from the Actions tab (workflow_dispatch), or from the CLI:

gh workflow run compat.yml --repo Pixnop/Atlas

workflow_dispatch accepts an optional versions input (space- or comma-separated) to sweep a custom set of versions instead of the default matrix (1.18.15, 1.19.8, 1.20.12, 1.21.7, 1.22.0, 1.22.1, 1.22.2, 1.22.3):

gh workflow run compat.yml --repo Pixnop/Atlas -f versions="1.22.0,1.22.3"

Clone this wiki locally