ADR-012 — Stratégie de versionnement et stabilité ABI

Trois zones de stabilité différenciées :

1. air-stable — APIs C-ABI publiques (couches 1, 2, partie consommable de 3 et 4). Stabilité ABI garantie sur 10 ans (5 ans release + 5 ans support étendu). Mécanisme : versioned symbols GNU/Linux. Deprecation : 5 ans minimum entre annonce et retrait. Modèle : glibc.

2. air-internal — APIs Rust entre crates Air. Stabilité source SemVer dans un release majeur. Pas de stabilité ABI. Refactorisation libre entre majeurs.

3. air-experimental — APIs nouvelles en évaluation. Aucune stabilité. Préfixées explicitement. Promotion à air-stable après un release majeur d’usage et RetEx.

Versionnement majeur.mineur.patch. Majeur tous les 5-10 ans. Mineurs ajoutent des APIs sans casse. Patches : bug fixes.

Support en parallèle : releases majeurs N et N-1 supportés simultanément. Cohabitation Side-by-Side sur une même machine (chemins versionnés, dispatch au runtime selon air-runtime demandé par l’app).

Cas spéciaux : AirCom (schémas Cap’n Proto avec règles d’évolution strictes), entitlements (noms jamais renommés ni retirés), format .airapp (manifest-version lu depuis v1).

Période 0.x exploratoire de 12-24 mois après phase 4 (air-base 1.0) avant fixation air-stable définitive. Modèle inspiré de Rust.

Outils mainteneurs : air-abi-check, air-symver, air-deprecation-tracker à intégrer dès la phase 0.

Licence du document : MPL 2.0 Statut : Document fondateur. Édition directe autorisée en phase de design pré-ouverture publique ; immuable après ouverture publique (toute évolution via RFC, cf. ADR-015).