Distribution & packages

Shared code is distributed through git tags (Rust crates) and npm (frontend libs). A module never links against the core.

Rust crates (tagged git dependencies) #

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)

Frontend libs (npm, @kubuno scope) #

@kubuno/ui, @kubuno/sdk, @kubuno/drive — published publicly, consumed at build time.

.kbpkg package layout #

<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 #

Every repository has CI workflows (.github/workflows/build.yml for Linux, dist.yml for Windows and macOS) that, on pushing a v* tag, build the .kbpkg (with SQLX_OFFLINE=true) and attach it to a GitHub Release.

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

Remember

Development follows a "published" model: to propagate a change to a crate or an @kubuno/* lib, republish it, then bump the dependency in the modules. This mirrors production exactly.