Confusione nei rilasci per quanto riguarda l'SDK soprattutto

[lleoncavallo]

Buongiorno,

segnalo una certa difficoltà nel mantenersi allineati con i frequenti rilasci che spesso sono molto poco documentati per cui non si riesce a valutare l'effettiva necessità di aggiornamento. Sarebbe molto utile a tutti noi se si spendesse qualche riga di descrizione sulle modifiche introdotte e si indicasse con chiarezza per ogni rilascio se è strettamente necessario allinearsi per rispettare la normativa vigente. Ad esempio sulla versione 1.2.3 sembrava quasi dal commento della commit che si trattasse di una modifica a livello di GUI.

Sarebbe utile per ogni rilascio avere queste informazioni:

• Breve descrizione delle ragioni del rilascio;
• Se il rilascio è un aggiornamento mandatorio o meno;
• Nel caso in cui fosse mandatorio la data a partire dalla quale deve essere reso disponibile;

Grazie, Lamberto

[rawmain]

Buongiorno @lleoncavallo

frequenti rilasci che spesso sono molto poco documentati per cui non si riesce a valutare l'effettiva necessità di aggiornamento.

Gli strumenti di riferimento, onde tener traccia degli update DGC-SDK sono di base :

1. DGC-SDK Release Branch diff/compare = usando già gli strumenti disponibili per il watch/monitoraggio delle attività nella repo è possibile infatti individuare con precisione modifiche/aggiornamenti prodrelease. Vedansi p.es. per le ultime 3 versioni

• • diff 1.1.1->1.1.2 = fix Realm + refactoring + supporto CRT E Exemptions (Certificati Digitali di Esenzione Vaccinale)
• • diff 1.1.2->1.1.3 = aggiunta del supporto alle nuove Medical Rules differenziate IT / NOT_IT introdotte in Validation Rules
• • diff 1.1.3->1.1.4 = aggiunta dello scanmode SCHOOL (tipologia di verifica STUDENTI)

A cui va aggiunta la relativa documentazione (che viene aggiornata solo dopo che le modifiche passano in produzione / pubblicazione storerelease verifier-app VerificaC19)

2. Changelog sintetico versioni DGC-SDK

3. Repo documentazione ufficiale

Nota a margine : Vi è stato un innegabile rallentamento negli aggiornamenti documentazione dopo la prodrelease DGC-SDK 1.1.2, ma dovrebbe esservi comunque il riallineamento entro il 15/02 (passaggio in produzione dello scanmode WORK). Vedansi anche attività in relative feature branch e PR tracker (dove sono già infatti visibili i flussi scanmode aggiornati - sia per attuale versione 1.1.4 che per prossima 1.1.5).

se è strettamente necessario allinearsi per rispettare la normativa vigente.

Si.

App/soluzioni terze usate in ambito ITA pub/produzione, che effettuino validazioni DGC in conformità alle prescrizioni normative, quindi integrando/usando solo SDK/Lib autorizzati ex DPCM 12/10/2021 (cioè questo DGC-SDK Android/Kotlin e SDK/Lib terze approvate dal Ministero della Salute) devono mantenersi allineate con aggiornamenti/modifiche.

Tali modifiche tecniche derivano appunto da prescrizioni normative (DL/DPCM) & indicazioni del Ministero della Salute + organi competenti, che sono pub & contengono le date di riferimento entro le quali devono essere effettivi gli adeguamenti tecnici - sia della verifier-app VerificaC19 che delle app/piattaforme autorizzate/conformi per validazioni DGC in Italia (ved. DPCM 12/10/2021).

Per questa ragione tanto le prodrelease DGC-SDK Android/Kotlin quanto quelle whitelabel-app/UI Android vengono infatti rese disponibili di base tra le 48 e le 72h prima della pubblicazione storerelease verifier-app VerificaC19.

Ciò viene effettuato, proprio onde ridurre il rischio di disallineamenti prolungati da parte di developer/publisher, che non stiano monitorando in linea anche le attività pub nelle active/feature branch, ma controllino solo gli aggiornamenti in tag/release tracker.

[lleoncavallo]

Grazie mille per la veloce risposta, immagino il prossimo rilascio avverrà attorno a venerdi prossimo.

[rawmain]

Buongiorno @lleoncavallo

Grazie mille per la veloce risposta

Prego ;).

immagino il prossimo rilascio avverrà attorno a venerdi prossimo.

In assenza di eventuali variazioni delle disposizioni/prescrizioni, tale è la scaletta preventivata, onde concedere appunto agli sviluppatori terzi di aggiornare la versione DGC-SDK in uso, senza ridursi all'ultimo minuto / bucare l'allineamento dal 15/02.

Lo scanmode WORK è già stato promosso feature->develop.

Attualmente sono in lavorazione/verifica le modifiche per le nuove Medicinal Rules IT / NOT_IT, onde recepire pienamente le disposizioni dell'Art.3 del DL n°5/2022 04/02/2022 in merito alle validazioni dei DGC emessi da Stati esteri - anche in caso di medicinal product (vaccino) non incluso in lista EMA.

[DevTrevi]

Buongiorno @rawmain, per quanto riguarda il rilascio delle librerie di terze parti, dovendo queste essere allineate a una versione dell'sdk ufficiale immagino che non possano includere feature come la modalità WORK prima che sia rilasciata ufficialmente, giusto?

E' vero che gli sviluppatori di librerie di terze parti possono effettuare i rilasci entro la scadenza, ma rilasciando le librerie così a ridosso dell'entrata in vigore, gli integratori che le utilizzano e che devono aggiornare le applicazioni e gli impianti dai clienti non hanno modo di rispettare le scadenze... L'ideale sarebbe poter rilasciare le librerie/sdk almeno una settimana prima dell'entrata in vigore dei decreti, pensi sia fattibile per le prossime versioni?

[rawmain]

Ciao @DevTrevi

per quanto riguarda il rilascio delle librerie di terze parti, dovendo queste essere allineate a una versione dell'sdk ufficiale immagino che non possano includere feature come la modalità WORK prima che sia rilasciata ufficialmente, giusto?

Se ci sono determinate condizioni iniziali / al contorno, in alcuni casi è anche possibile procedere "con un anticipo ridotto" in ambito di release intermedie / pre-release. Prendiamo ad esempio proprio lo scanmode WORK.

La sua (semplice) logica base - cioè la condizione addizionale test-over-50 per i soli DGC T ex DL n° 1/2022 07/01/2022 - era appunto implementabile in ambito di feature branch già da allora, mantenendola "parcheggiata" in attesa di stabilizzazione/conferme (ved. evoluzione disposizioni normative + successive indicazioni da Ministero della Salute / GPDP / organi competenti).

A distanza di quasi 1 mese, il DL n° 5/2022 04/02/2022 non ha comportato modifiche a tale logica base, ma solo variazioni sulle Validation Strategy generali (non specifiche del solo scanmode WORK) dei DGC V e R NOT_IT.

\ Pertanto, fermo restando che le validazioni con tipologia di verifica Lavoro sono/restano effettuabili solo a partire dal 15/02 ex DL n° 1/2022, già dal 4 Febbraio si poteva cmq iniziare ad anticipare i passaggi feature->develop->release per l'integrazione della sola logica base scanmode WORK in ambito di release intermedie / pre-release.

Vedasi ad esempio quanto fatto per la libreria C++ by Solari, che ha appunto già integrato la logica base WORK sin dalla release intermedia 1.1.4 del 4 Febbraio, prima della "promozione" della logica base WORK nelle repo ufficiali VerificaC19 (avvenuta ieri). Ciò, onde consentire ai relativi integratori di effettuare già alcuni test con un minimo anticipo, senza ridursi a farli tutti all'ultimo.

Alcuni test, non tutti, poiché (alla stregua delle altre librerie, incluso questo DGC-SDK) non sono ancora state "promosse" le nuove Validation Strategy per i DGC V e R NOT_IT, essendo queste ancora WIP. Vedasi attesa conferme per nuove medicinal rules EMA / NOT_EMA & lock/unlock esito TEST_NEEDED dei DGC V Ciclo e R NOT_IT > 180gg, da applicare per scenari diversi da verifica Base ex Art.3 DL n° 5/2022.

---

L'ideale sarebbe poter rilasciare le librerie/sdk almeno una settimana prima dell'entrata in vigore dei decreti, pensi sia fattibile per le prossime versioni?

Sarebbe l'ideale, ma appunto non vi sono sempre le condizioni reali, onde rilasciare prodrelease definitive (non release intermedie / pre-release) con 7gg+ di anticipo.

Da un lato per la breve distanza temporale tra pubblicazione ufficiale di alcune disposizioni e l'entrata in vigore a regime delle relative modifiche previste.

Dall'altro perché è necessario attendere le conferme di determinate impostazioni/tarature, che - in presenza di tempistiche ristrette - finiscono per arrivare a ridosso delle deadline.

[DevTrevi]

Ti ringrazio @rawmain, per le successive feature allora mi organizzerò con delle versioni di pre-release

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.