# APIZIT Linking 0.4.0

Version 0.4.0 turned the compiler-to-runtime handoff into an explicit, fail-closed contract and gave external adapters a supported integration path that does not vendor engine source.

**Publication status:** 0.4.0 is available from [PyPI](https://pypi.org/project/apizit-linking/0.4.0/). PyPI distributions are canonical; this examples repository does not mirror them as a GitHub Release.

## Install and verify {#install}

Terminal

```text
python -m pip install "apizit-linking[preview]==0.4.0"
python -m pip show apizit-linking
apizit-linking validate .
```

## Release highlights {#highlights}

### Closed runtime artifact v1

Compiler output consumed by an adapter is no longer an anonymous list of routes. The closed envelope requires `format`, `version`, `engine_version`, `manifest_version`, and `routes`. Unknown or malformed fields are rejected so a deployment never guesses how to execute an artifact.

### Strict callable drift detection

Each compiled route records ordered parameter names, parameter kinds, required and default state, annotations, `callable_kind`, and `return_annotation`. The runtime compares every recorded dimension with the imported function before the application starts. Renaming, reordering, adding, removing, or re-annotating a parameter therefore requires recompilation.

### Generators fail closed

Synchronous and asynchronous generators are rejected during compilation and checked again when loading an artifact. Streaming needs a separate lifecycle, cancellation, media-type, and error contract; 0.4.0 does not infer one.

### Public canonical manifest schema

Manifest `version: 1` has a closed Draft 2020-12 [JSON Schema](/apizit-linking-examples/schema/apizit-linking-v1.schema.json). Editor validation and `apizit-linking validate` complement one another: the schema checks the authoring shape, while the compiler resolves functions and verifies semantic bindings.

### Supported non-vendored adapter API

APIZIT and other deployment systems can pin the PyPI package, call `compile_linking_file`, serialize `CompilationResult.to_runtime_dict()`, and later create the HTTP application with `create_app_from_runtime_artifact`. The adapter treats the artifact as opaque and no longer copies private engine modules.

## Compatibility consequences {#compatibility}

- Manifest version 1 remains independent from package version 0.4.0.
- Runtime artifact format version 1 describes the serialized shape.
- `engine_version` must match exactly, even while artifact `version` remains 1.
- Every engine upgrade requires a fresh compilation; generated artifacts are never edited by hand.
- The old `create_app_from_runtime_routes` entry point is only a migration bridge for unversioned route lists.

Read the complete [compatibility policy](/apizit-linking-examples/reference/compatibility/) before building an external adapter.

## Migration and deployment action {#migration}

Projects moving from 0.3 should follow the [0.3-to-0.4 guide](/apizit-linking-examples/migrations/0.3-to-0.4/). APIZIT must pin the released package, compile the manifest during its build, record the engine version and artifact hash, and package the artifact with the exact same runtime dependency. Existing ZIP or image outputs must be rebuilt.

## Known boundaries {#limits}

Version 0.4.0 does not make preview a production server or sandbox. That historical release did not support declarative custom status codes, response headers or complete OpenAPI models. Current Linking 1.0 adds response configuration and optional typed models; streaming remains outside its JSON API contract. See the [current V1 limits](/apizit-linking-examples/limits/).