Versioni e branch: cosa gira dove

Aggiornato al 27/10/2026.

Verifica mirata del 28/10/2026: il branch remoto mdm_installation/stage è al commit d02dbaeedf52d1bb96f428c1b927e15dd8f3d6aa (03/08), con immagine pubblicata 3.9.0-stage e tag wrapper dichiarato 3.4.0-stage. La 3.9.0-stage è stata installata sul solo box di prova MDMTESTGANZ1, collegato al midserver dev; i riferimenti alla nuova versione nelle analisi precedenti descrivono la ricostruzione iniziale. Non è stato rifatto il confronto completo dei branch. Dettagli e verifiche.

Componenti

Componente	Prod	Dev (Coolify)	Branch "futuro"
Midserver	mid-server:2.2.0 (Flask, branch main, build locale sul server)	v3.0.0 (refactor/v1)	refactor/v1
Pannello MDM	mdm_panel:1.8.0 (ECR)	branch dev	dev → main
Box	3.1.9–3.2.9 (linea main, ultima 3.2.9 del 03/08)	—	stage (3.9.0-stage del 03/08, solo sul box di prova)
Frigate wrapper	segue la linea del box	—	stage
qAlarm 2 BE/FE	non in prod	deploy_dev (auto-deploy)	main
ewelink-integration	build locale = repository	—	da portare nel midserver

Distribuzione delle versioni sul parco (censimento del 28/10/2026, 28 box che rispondono): 3.1.9 → 10, 3.2.1 → 2, 3.2.2 → 2, 3.2.9 → 15. Frigate 0.17.1 su tutti i 25 box con Frigate; 4 box 3.1.9 usano il detector GANZ. L'allineamento a 3.2.9 (T9.1) riguarda quindi circa 14 box. Vedi censimento.

Convenzione dei branch

Convenzione usata in molti progetti (non in tutti), confermata il 28/10/2026:

Branch	Contenuto
main	versione di produzione
stage	versione in sviluppo destinata alla produzione: contiene il codice più aggiornato

Il flusso atteso è: si sviluppa su stage, si prova, poi si porta su main per il rilascio. Le correzioni urgenti fatte su main vanno riportate su stage.

Repository	Segue la convenzione?	Produzione	Prossima versione
mdm_installation	sì	main (3.2.x)	stage (oggi 3.9.0)
mdm_frigate_wrapper	sì	main	stage
mdm_privacy_mode	sì per la build (main)	main	—
mdm_mid_server	no	main (Flask 2.2.0)	refactor/v1 (v3); dev è il Flask 2.4.0, fermo
mdm_web_panel	no	main	dev
qAlarm2_be, qAlarm2_fe	no	main	deploy_dev (deploy automatico su Coolify dev)
infra-lib	un solo branch	main (v0.1.9, 12/05/2026)	— (il box stage lo fissa al commit 66379db, v0.1.9)
monitoring	no	main (21/05/2026, mai in esercizio)	dev (18/06/2026, su Coolify dev)

Conseguenze: - In mdm_installation la convenzione non è stata rispettata fino in fondo: main ha ricevuto 42 correzioni mai riportate su stage (T2.1, MDM-030). Analisi del 29/10/2026: quattro comportamenti da riscrivere in stage, il resto è già presente o non serve; al 30/10 i quattro sono committati su origin/stage (fino a ebde226c) (dettaglio). D'ora in poi ogni correzione su main va riportata subito su stage. - Per il midserver, la "prossima versione" è refactor/v1, non stage. Proposta: quando la v3 sarà la base ufficiale, adottare la stessa convenzione (refactor/v1 → stage, main = produzione) e archiviare dev. - I canali di aggiornamento dei box seguono la stessa logica: canale production = branch main, canale stage = branch stage (update.yml).

Midserver: branch

Branch	Ultimo commit	Contenuto rispetto a refactor/v1	Verdetto
main	25/05	Flask 2.2.0 (prod)	funzioni già nella v3
dev	03/06	Flask 2.3.0/2.4.0: node_id, IO config, URL di playback OME dinamico	node_id e IO config presenti nella v3; da verificare l'URL di playback OME dinamico (commit 6dd5e6b)
refactor/v1	18/06	v3.0.0	base per la prod
trace, refactor/deploy-patches	21/05, 15/06	niente di nuovo	eliminabili
feat-io-config, feat_installation_infos, feat_presigned_url_from_event	apr–mag	già confluiti	eliminabili
e2e	03/06	test end-to-end sull'API Flask	da riusare come test di compatibilità contro la v3
unit_tests_backup	12/05	backup di test	obsoleto

Box: linee main e stage

• Divergono dal 02/02/2026: 637 commit solo su stage, 42 solo su main.
• Le funzioni async/callback, receive_log e chat/snapshot sono nel client dei box dalla 1.9.4 (novembre 2025): tutti i 38 box le chiamano.
• Tutti i box sono sotto la 10.0.0: la v3 del midserver userà con loro i topic MQTT vecchi.
• Decisione 27/10/2026: la nuova versione andrà in prod; le 42 modifiche di main vanno riportate su stage prima del test completo in dev.

Due linee in parallelo: matrice di compatibilità da provare

Midserver ↓ / Box →	3.1.9	3.2.9	linea stage
v2 (prod)	✅ in uso	✅ in uso	❓ mai provato
v3 (dev)	❓	❓	❓ (pensato per questa)

Obiettivo del piano: riempire questa tabella con test reali su Coolify dev prima di qualsiasi passaggio in prod.