astrolabio-virgostars-updates

Astrolabio Virgo Stars — Update Feed

Repository pubblico usato come feed statico dei metadata degli aggiornamenti Astrolabio.

Dominio configurato tramite CNAME:

astrolabio-updates.virgostars.it

Responsabilità

Questo repository contiene il puntatore alla prossima release compatibile per ogni modello/canale.

Gli artifact reali sono separati perché possono includere backend, UI, Node ARM64, dipendenze e browser headless:

astrolabio-updates.virgostars.it
└── metadata statici latest.json

cdn.virgostars.it/astrolabio/releases
└── artifact .tar.gz reali

Canali

lab/
  6p/latest.json
  7.8p/latest.json

stable/
  6p/latest.json
  7.8p/latest.json

lab

Usato soltanto per candidate e hardware di laboratorio.

Una release deve passare prima da lab per:

• download reale;
• installazione;
• reboot;
• /health;
• /health/loop;
• display;
• rollback;
• compatibilità 6”/7,8”;
• oldest supported field baseline.

stable

Visibile agli Astrolabi degli utenti.

Non pubblicare una candidate direttamente su stable.

Stato sicuro senza release

Quando un canale/modello non deve offrire nulla:

{
  "channel": "stable",
  "model": "6p",
  "family": "eink-small",
  "latest": null
}

Attualmente sia lab sia stable sono inizializzati in questo stato per 6” e 7,8”.

Non pubblicare placeholder/mock come latest.

Regola di pubblicazione

Aggiornare latest.json soltanto dopo:

1. build artifact;
2. upload artifact CDN;
3. verifica SHA-256/dimensione/URL;
4. validazione del package parser usato dal device;
5. installazione su Astrolabio campione;
6. reboot e health;
7. rollback test;
8. compatibility test appropriato.

Ordine:

build
→ CDN
→ verifica
→ lab latest.json
→ hardware E2E
→ field-baseline test
→ stable latest.json

Contratto latest.json

Esempio:

{
  "channel": "stable",
  "model": "6p",
  "family": "eink-small",
  "latest": {
    "version": "1.2.0",
    "publishedAt": "2026-08-11T18:00:00Z",
    "title": "Titolo release",
    "notes": ["Nota"],
    "mandatory": false,
    "minSupportedVersion": "1.0.26",
    "asset": {
      "file": "astrolabio-update-1.2.0-6p.tar.gz",
      "url": "https://cdn.virgostars.it/astrolabio/releases/1.2.0/astrolabio-update-1.2.0-6p.tar.gz",
      "sha256": "...",
      "sizeBytes": 123456
    }
  }
}

Il feed pubblico usa 7.8p; i boundary legacy normalizzano anche 7_8p.

Compatibilità legacy

latest significa prossima release compatibile, non necessariamente la versione numericamente massima.

Esempio:

1.0.x legacy
→ bridge
→ nuova infrastruttura applicativa
→ release successive

Un bridge deve restare disponibile finché esistono device supportati che ne hanno bisogno.

Sicurezza

SHA-256 protegge l’integrità, non l’autenticità del produttore. Le future Host Migrations privilegiate richiedono release signing.

Documentazione canonica:

virgo-stars/docs/astrolabio/BRIDGE_CANDIDATE_1_0_27.md
virgo-stars/docs/astrolabio/AUTOMATIC_UPDATE_AND_LEGACY_COMPATIBILITY.md
virgo-stars/docs/astrolabio/HOST_MIGRATIONS_V2_DESIGN.md