Aquesta és una versió anterior. La versió actual és la 2.3.0. LobeHub 2.3.0 · Data de publicació:
Fitxers d’instal·lació 2.1.56
| Arquitectura | Tipus | Àmbit | Mida del fitxer | Baixa | SHA256 |
|---|---|---|---|---|---|
| 64 bits | EXE (NSIS) | Usuari actual | — | github.com | VirusTotal |
| 64 bits | EXE (NSIS) | Tots els usuaris | — | github.com | VirusTotal |
L’enllaç i l’SHA256 provenen del manifest comunitari del Gestor de paquets del Windows. Convé comparar el hash del fitxer baixat abans d’executar-lo.
Notes de la versió
This release was automatically published from PR #14354.
Changes
See PR description: https://github.com/lobehub/lobehub/pull/14354
Commit Message
🚀 LobeHub v2.1.56 (20260501)
Release Date: May 1, 2026
Migration Scope: briefs table — 2 new columns (trigger, metadata), 1 new index (briefs_trigger_idx)
🗄️ Migration Overview
File: packages/database/migrations/0100_add_metadata_and_trigger_to_briefs.sql
Added columns on briefs:
- trigger varchar(255) — module that triggered the brief (e.g. task, agent, signal)
- metadata jsonb — freeform business state attached by the producer
Added index:
- briefs_trigger_idx on briefs(trigger)
The migration uses ADD COLUMN IF NOT EXISTS and CREATE INDEX IF NOT EXISTS, so re-running it is safe.
⚙️ Operator Notes
- Migration runs automatically on application startup.
- Both new columns are nullable — existing rows are unaffected and no backfill is required.
- The migration is additive only; no existing column or index is modified or dropped.
- Recommended: take a routine snapshot before deployment, as with any schema change.
🔒 Reliability & Risk
- Backwards-compatible: Older application code that does not read or write trigger / metadata continues to work, since both columns are nullable.
- Index cost: briefs_trigger_idx is built with IF NOT EXISTS and is small (single varchar(255) column); build time on existing data is expected to be negligible.
- Rollback: If a rollback is required, drop briefs_trigger_idx and the two new columns; no data migration is involved.
👥 Owner
Migration owner: @nekomeowww
The migration owner is responsible for rollout follow-up and incident handling for this schema change.