Releases

Oliphaunt products are released independently. Start from the package your app installs, then check the runtime artifacts and selected extensions that package expects.

Read releases by the app artifact you ship

Match the SDK package, runtime artifacts, selected extensions, and performance notes before updating an installed app.

Which package version fits my app?

Start with the SDK package, then check the runtime dependency it carries.

Version Matrix

Which compatibility updates move together?

Runtime changes can select dependent SDK releases, but every SDK keeps its own SemVer.

SDKs And Platforms

Which extensions can this release ship?

Check extension availability by SQL extension name and target runtime.

Extension Catalog

Did performance or package size change?

Read release measurements by workload, target hardware, and selected extensions.

Performance

First Release Boundary

Before the first public release, tracked product versions remain 0.0.0. That is an unreleased source sentinel, not a registry version. The generated release PR advances new products to 0.1.0, except Swift, which starts at 0.6.0 because legacy unscoped SwiftPM tags already occupy 0.1.0 through 0.5.1.

An install command is a package contract, not proof that a registry identity exists. Check the product's promoted tag/release and registry page before using it in an application.

Version Relationships

Relationship	Products	Rule
Independently versioned	Native, WASIX, contrib, SDKs, and helper runtimes	Release Please selects changed product paths; each product owns its SemVer, and native and WASIX do not move together
Directed compatibility	Products with exact dependency or runtime compatibility fields	A changed dependency can select its consumer, but selection never travels backwards and does not create a shared version
Upstream-bound	External exact-extension products	Packaging SemVer is independent; immutable upstream version/commit and compatible runtime versions are recorded separately
Documentation	Public documentation site	Guides and references can change without a package release

React Native spans two native platform SDKs. A JavaScript package release may need matching Swift and Kotlin artifacts even when the TypeScript API shape is unchanged.

Target Availability

The first native desktop carriers cover Linux x64/arm64 GNU, macOS arm64, and Windows x64 MSVC. Android carriers cover arm64-v8a and x86_64. Apple uses the declared iOS XCFramework plus the macOS arm64 runtime carrier. WASIX ships a portable carrier and AOT carriers for the supported desktop hosts.

macOS x64, Windows ARM64, Linux musl, Android 32-bit, and undeclared Apple architectures are not first-release targets. An extension can support a smaller set: its own explicit target manifest and published carrier metadata are authoritative.

Consumer Compatibility Floors

The release gate inspects staged binaries against the following contract. These are consumer compatibility floors, not merely the operating systems used to build the artifacts.

Published carrier	Enforced consumer compatibility contract
Linux x64/arm64 GNU	Required symbol versions do not exceed `GLIBC_2.38` or `GLIBCXX_3.4.30`.
Direct macOS arm64 runtime	Minimum deployment target is macOS 11.0.
Android `arm64-v8a` and `x86_64`	Minimum Android API level is 24; Android binaries must not require GLIBC/GLIBCXX symbol families.
Apple XCFramework	Contains macOS arm64, iOS device arm64, and iOS Simulator arm64 slices; minimum targets are macOS 14.0, iOS 17.0, and iOS Simulator 17.0.
Windows x64 MSVC	Requires the x64 PE/COFF contract and the declared app-local Visual C++ runtime profile; Windows ARM64 is not published.

The table is synchronized with the authoritative binary compatibility policy used by release staging. A carrier fails qualification when its inspected ELF, Mach-O, Android, or PE metadata exceeds this contract.

Mobile Package And Runtime Coverage

Package availability and installed-app execution are separate support claims:

Surface	Built and binary-inspected release candidates	Required installed-app execution
Android	Both `arm64-v8a` and `x86_64` runtime and exact-extension carriers, plus release APKs for both ABIs	The `x86_64` APK runs the full installed-app workload on the API 35 emulator. Android arm64 is not executed on a physical device in the required first-release gate.
Apple	The XCFramework's macOS arm64, iOS device arm64, and iOS Simulator arm64 runtime and exact-extension slices	The iOS Simulator arm64 app runs the full installed-app workload. The iOS device arm64 slice is built and inspected, but is not installed or executed on a physical iOS device in the required first-release gate.

This boundary does not mean that Android arm64 or iOS device packages are absent. It distinguishes artifact construction and binary compatibility proof from hardware-specific execution coverage, so release notes state exactly which installed-app workloads are required for each platform.

What A Release Tells You

Release notes answer these questions:

PostgreSQL baseline used by the runtime;
SDK packages published in the release;
platforms and architectures with artifacts;
exact SQL extensions available for each target;
direct, broker, server, raw protocol, streaming, backup, and restore support;
migration or rebuild steps for app developers.

Docs Versioning

The docs site has a latest channel for the current product shape. Package versions, compatibility notes, and release notes tell developers which docs match the SDK installed in an app. Versioned docs remain available by released product version when a package line needs stable historical documentation.

Documentation changes can update the docs site without changing Rust, Swift, Kotlin, React Native, TypeScript, C ABI, or WASM package versions.