Aller au contenu principal

appcore-sdk

Release candidate

Publié et vérifié au registre : 1.0.2-rc.4, 2026-11-09. Sélectionner =1.0.2-rc.4 explicitement. Les versions restent indépendantes ; ceci est une release candidate, sans certification de déploiement ou de matériel.

ID stable de documentation : ACR-028.

appcore-sdk est la façade des applications. Il offre une petite surface orientée manifestes tandis que les crates spécialisés gardent la responsabilité du stockage, scheduling, sync, AI, documents et déploiement.

Il remplace appcore-bin, désormais retiré, sans conserver l'ancien host ni la CLI Runtime.

Migration depuis appcore-bin

La dernière version de appcore-bin sur crates.io n'est qu'un avis de retrait. Les nouvelles applications doivent dépendre directement de appcore-sdk. Les applications existantes conservent leurs manifestes et leur code métier, remplacent les imports appcore_bin et laissent providers, listeners, workers et shutdown à l'exécutable de déploiement.

Quand l'utiliser​

  • pour démarrer une application AppCore externe à partir des trois artefacts ;
  • pour implémenter Application et enregistrer commands, events, queries, decisions, states, handlers ou tasks ;
  • pour employer les defaults locaux canoniques avant de fournir des manifests V1 explicites ;
  • pour activer des namespaces de capabilities sans composer manuellement un host Runtime.

Il n'ouvre aucun listener implicitement, ne choisit pas de provider, ne résout pas de secret et ne contrôle pas le lifecycle du processus. La composition du déploiement reste explicite.

Contrats principaux​

  • run et App fournissent le plus petit contexte local validé ;
  • Application définit les hooks d'enregistrement appartenant à l'application ;
  • manifest réexporte les contrats canoniques de manifest V1 ;
  • les namespaces protégés par features exposent les contrats API, deployment, scheduler, storage, sync, AI et FileMaker ;
  • App::logging configure le pipeline borné d'appcore-log.

Commencez par le tutoriel, le guide en anglais, le guide en portugais ou le guide en français. Exécutez ensuite l’exemple de base et l’exemple intermédiaire.

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

1.0.2-rc.1: modifications propres.

crates.io · docs.rs

1.0.2-rc.3​

Les pins exacts sélectionnent la distribution de sécurité IA et la RC FileMaker qualifiées selon le cas. APIs publiques, features par défaut et entrées V1 restent inchangées. Sélectionner la release exacte et actualiser explicitement le lockfile complet ; les anciens pins restent immuables. Le backend optionnel utilise les distributions de sécurité du registre documentées sur la page AI. Ceci ne certifie pas le matériel et ne migre pas une application externe.

Disponibilité HA négociée — 1.0.2-rc.4​

Cette cohorte RC aligne les types distribués entre Sync, Peer RPC, control plane, Gateway, Transfer, SQLite et SDK. peer.availability.v1 sélectionne des résultats authentifiés et structurés sans modifier V1. Busy n’exécute pas la closure et ne confirme aucun travail. Rejet, attente, transport et confirmation durable restent distincts; les reprises conservent la même identité idempotente. Le déploiement garantit la fin de la closure, le fencing exact et la confirmation du réplica. Aucune migration, installation ou certification de coupure électrique n’est implicite.

Voir le guide de disponibilité.