Distribution & paquets

Le code partagé se distribue par git-tags (crates Rust) et npm (libs frontend). Un module ne lie jamais le core.

Crates Rust (dépendances git taguées) #

kubuno-seccomp  → git = kubuno/core,  tag = seccomp-v0.1.0
kubuno-storage  → git = kubuno/core,  tag = storage-v0.1.0
kubuno-drive    → git = kubuno/drive, tag = drive-v0.1.0  (client, default-features=false)

Libs frontend (npm, scope @kubuno) #

@kubuno/ui, @kubuno/sdk, @kubuno/drive — publiées publiquement, consommées au build.

Layout du paquet .kbpkg #

<id>-<version>-<os>-<arch>.kbpkg   # archive ZIP
├── module.toml              # manifeste
├── kubuno-<id>[.exe]        # binaire
├── frontend/
│   ├── entry.js             # bundle du module
│   └── entry.css            # styles du module
├── migrations/              # SQL (référence)
├── config.toml.example, LICENSE, CHANGELOG.md
└── SHA256SUMS               # empreintes, vérifiées à l'installation

/var/lib/kubuno/modules-store/<id>/           # la racine y est déballée telle quelle
/var/lib/kubuno/                              # données, thèmes, modules installés

Releases & CI #

Chaque dépôt a une CI (.github/workflows/build.yml pour Linux, dist.yml pour Windows et macOS) qui, sur push d'un tag v*, construit le .kbpkg (avec SQLX_OFFLINE=true) et l'attache à une Release GitHub.

bash _tools/release.sh <module> <version>   # ex: release.sh calendar 0.1.0 → tag v0.1.0 + push

À retenir

Le mode de dev est « publié » : pour propager un changement d'une crate ou d'une lib @kubuno/*, republiez puis bumpez la dépendance dans les modules. Cela reflète exactement la prod.