-   [](https://platform.exaloop.io/)
-   Releases and Compatibility

# Releases and Compatibility

Each Exaloop distribution is a matched release of the compiler, SDKs, generators, and native tools for one platform. Keep those components together: matching version strings alone do not guarantee binary compatibility.

Use this guide to check host requirements, identify the active installation, and plan an application upgrade. Release-specific changes and support coverage are supplied with the distribution or through your Exaloop representative.

## Platforms

| Archive platform | Host requirements |
| --- | --- |
| `darwin-arm64` | Apple Silicon, macOS 14 or newer; Apple Command Line Tools for builds |
| `linux-x86_64` | x86-64 Linux with glibc 2.39 or newer, such as Ubuntu 24.04 |
| `linux-aarch64` | AArch64 Linux with glibc 2.39 or newer, such as Ubuntu 24.04 |

Compilation targets the current native platform. Selecting extension metadata does not cross-compile a library for another architecture or operating system. macOS binaries are ad-hoc signed, not notarized.

## Identify an Installation

```sh title="Terminal"
exaloop distribution verify
exaloop plugin list
exaloop doctor --json
```

These commands check distribution integrity, list the selected SDKs, and report toolchain diagnostics. For a server target, `exaloop --target NAME doctor --json` also checks the host tooling needed by that target.

Profiling and optimization have additional native requirements, checked by `exaloop doctor --profiling` and `exaloop doctor --optimization`. A matching version number alone does not establish that a capture or PGO backend is usable.

## Integration Compatibility

Database client applications and server extensions have different requirements. A client communicates over the database protocol; an extension loads into the server process and must match its native interface. The [database compatibility table](https://platform.exaloop.io/db/reference/#compatibility) lists those constraints by integration.

The [SDK guide](https://platform.exaloop.io/start/install/#requirements) covers separately supplied SDKs. Generated Avro and Protobuf code should be regenerated with the generators from the active distribution when changing releases.

## Update a Distribution

Updates use another local tarball supplied by Exaloop. The [installation guide](https://platform.exaloop.io/start/distribution/#use-and-updates) covers checksum verification, activation, and rollback. Older releases remain available locally until removed, so returning to an earlier installation does not require network access.

For reproducible builds, a [project lock](https://platform.exaloop.io/start/distribution/#project-lock) records the active distribution. Each lock is platform-specific; projects built for multiple architectures need a corresponding lock for each build environment.

## Plan an Application Upgrade

The relevant compatibility checks are the destination platform, native libraries, database host version, generated code, and application behavior. A staging run with representative data helps detect changes in results or resource use before deployment. The [production checklist](https://platform.exaloop.io/production/#production-checklist) provides a common set of operational checks.

Source: https://platform.exaloop.io/releases/