Aller au contenu principal

appcore-update

Paquet publié

Release candidate 1.0.3-rc.2 · MSRV Rust 1.89 · crates.io · docs.rs · code source

Guide et exemples maintenus par le crate​

Le dépôt Runtime maintient le guide détaillé, exemple débutant et exemple intermédiaire. Le wiki résume la frontière publique ; les détails d’API et d’exécution restent avec le code du crate.

Responsabilité : sélection, authenticité, staging, activation, health gate et rollback d'artefact opaque.

Dépendances internes : contracts et provider.

API principale : artifact descriptor/signing payload; verifier, unsigned-local protégé par feature/Ed25519, trust policy/key status; update request/provider et file factory; staged artifact, activation receipt/store; coordinator, preparation/outcome, health check et fault injection.

À utiliser pour binaires ou artefacts opaques. Le Runtime valide identité, version, protocole, checksum et trust sans comprendre code ou schéma.

Les lectures fichier vérifient la taille avant l'allocation, utilisent un scratch fixe de 16 Kio plus un octet sentinelle non retenu et rejettent un composant final non régulier. L'activation revalide taille et SHA-256 du staged, puis crée un hard link vers un path de build immuable. Un path existant n'est réutilisé que si ses octets correspondent exactement au descriptor; il n'est jamais remplacé. Le no-follow atomique du composant final existe sous Unix. Les autres plateformes conservent les checks metadata mais dépendent de la frontière filesystem du déploiement contre les races de reparse.

Les pointers active/previous et les receipts d'activation pending empruntent leurs descriptors, passent un sizing sans rétention sous 1 Mio et sérialisent directement dans le temporaire atomique avec un buffer fixe de 16 Kio. Leur lecture désérialise aussi directement par un reader borné fixe de 16 Kio, sans conserver un vecteur complet d'octets encodés avec le pointer ou receipt décodé. L'absence, l'échec d'I/O et l'échec de décodage restent distincts afin de préserver l'upgrade wall de l'activation pending. Le JSON V1 reste inchangé.

Le file provider parcourt une seule fois l'index borné en streaming et ne retient que la meilleure version sémantique et son descriptor. Chaque descriptor est validé puis éliminé ou sélectionné pendant le décodage du tableau JSON, sans vecteur de descriptors ni liste triée de candidats. À version égale, la première entrée reste prioritaire. Un reader fixe de 16 Kio, un preflight de 1 Mio et un octet sentinelle non retenu rejettent une taille déclarée excessive et une croissance concurrente.

La release candidate expose aussi ReleaseCatalog borné et la recherche d’artefacts en streaming, des primitives de cache adressé par contenu et les métadonnées Recovery V2. QuarantineStore enregistre les candidats échoués afin que la sélection les exclue sans modifier le catalogue. La CLI appcore-update-diagnose ne lit que l’état local borné et émet des diagnostics rédigés pour les opérateurs.

Maturité : lifecycle de release candidate; la supply chain distante exige signature, provenance et trust roots.

Prérelease indépendante — 2026-10-14​

2.0.0-alpha.2: modifications propres.

crates.io · docs.rs

L’enum public exhaustif UpdateError ajoute Transfer et Recovery par rapport à la version stable 1.0.0. Ce changement d’API Rust exige une prérelease major explicite ; manifests V1 et protocoles des descriptors de mise à jour restent identiques. Migration : sélectionner appcore-update = "=2.0.0-alpha.2", traiter les deux nouvelles variantes, refaire les tests activation/récupération/rollback et conserver le binaire précédent et la sauvegarde vérifiée. Rollback : arrêter l’activation, restaurer le binaire précédent avec sa sauvegarde vérifiée d’état compatible ; ne jamais inférer ni convertir un état non supporté. Une dépendance 1.x ne sélectionne pas implicitement cette version major.