Grandi notizie! Quando si aggiunge una dipendenza da GitHub, ora si ha accesso a una nuova regola: Segui la versione 4D. Questa potente aggiunta garantisce che le dipendenze siano sincronizzate con l’ambiente 4D senza sforzo, riducendo i problemi di compatibilità e rendendo il flusso di lavoro più fluido che mai.

SEMPLIFICARE LA GESTIONE DELLE DIPENDENZE

Con la regola Segui la versione 4D, non è più necessario tenere traccia manualmente delle versioni delle dipendenze allineate alla versione 4D. Il Dependency Manager se ne occupa per voi, garantendo la selezione automatica delle versioni più pertinenti e compatibili. Questo significa:

• Meno lavoro manuale: non è necessario cercare da soli le versioni giuste.
• Meno problemi di compatibilità: le dipendenze corrispondono sempre all’ambiente 4D.
• Maggiore stabilità: il progetto funziona senza problemi anche in caso di aggiornamento o downgrade di 4D.

AGGIORNAMENTI SENZA SFORZO E COMPATIBILITÀ AFFIDABILE

Quando aggiornate la vostra versione di 4D, le vostre dipendenze rimangono valide e potete facilmente recuperare le ultime versioni compatibili. Se si esegue un downgrade, il sistema adatta automaticamente le dipendenze alla nuova versione.

ETICHETTATURA DEI RILASCI PER LA RISOLUZIONE AUTOMATICA

Per far funzionare efficacemente questo sistema, i collaboratori devono assicurarsi che le dipendenze seguano una convenzione strutturata di denominazione dei tag. Il Dependency Manager risolverà le dipendenze in base a queste regole di versionamento:

Versioni LTS : I tag devono seguire lo schema x.y.p, dove:

• x rappresenta la versione principale di 4D.
• y rappresenta la versione minore.
• p consente una certa flessibilità per le versioni patch o gli aggiornamenti aggiuntivi.

Esempio: 20.2.3 (Major: 20, Minor: 2, Patch: 3) o 21.6.1 (Major: 21, Minor: 6, Patch: 1).

Quando il progetto specifica che segue una versione 4D LTS (ad esempio, 20.2), il Component Manager cercherà sempre di risolvere il problema con l’ultima versione della serie 20.*, se disponibile. Se non si trova la versione esatta che si sta cercando, si ricorrerà automaticamente a una versione precedente di quella serie, come la 20.1.p o la 20.0.p, se disponibili.

Versioni R: i tag devono seguire lo schema `xRy.p`, dove:

• xR corrisponde alla versione principale della release.
• y rappresenta la versione minore.
• p consente patch e aggiornamenti incrementali.

Esempio: 20R3.2 (Major: 20R, Minor: 3, Patch: 2) o 21R5.1 (Major: 21R, Minor: 5, Patch: 1).

Quando il progetto specifica una release di R come la 20R3, il Component Manager cercherà innanzitutto di risolvere il problema con l’ultima versione della serie 20R3.p. Se questa versione non è disponibile, cercherà una versione della serie 20R* inferiore o uguale alla 20R3, come la 20R2.p o la 20R1.p.

I componenti4DPop e 4DPop-Macros aderiscono già alle convenzioni di etichettatura strutturate e garantiscono una risoluzione delle dipendenze senza problemi con la regola Follow 4D version.

Si noti che se si hanno componenti propri con regole di denominazione personalizzate, si può mantenere il numero di versione nel titolo. Tuttavia, il tag deve seguire rigorosamente il formato richiesto.

CONCENTRARSI SUL CODICE, NON SULLE DIPENDENZE

Con la versione Follow 4D, la gestione delle dipendenze non è mai stata così semplice. Sia che stiate aggiornando, declassando o mantenendo il vostro progetto, potete fidarvi del fatto che le vostre dipendenze saranno sempre in linea con il vostro ambiente 4D.

Provatelo subito e sperimentate un modo più intelligente e senza problemi di gestire le dipendenze!