A seconda della versione fissa di una libreria e ignorarne gli aggiornamenti

Se non è rotto, non aggiustarlo.

• Esiste una funzione che è davvero necessario utilizzare, disponibile nella versione più recente e che mancava in una versione precedente?

• C'è un problema (bug, problema di prestazioni, ecc.) che riguarda il tuo progetto ed è stato risolto nella versione più recente?

Se la tua risposta è "no" per entrambe le domande, non c'è davvero bisogno di aggiornamento, specialmente dal momento che l'aggiornamento a una nuova versione richiede di controllare se non si interrompe nulla nel tuo codice, cosa che a volte può essere complicata .

Se la tua risposta è "sì" per almeno una delle domande, dovresti decidere se l'aggiornamento alla nuova versione vale davvero la pena, tenendo presente il rischio di rompere il codice esistente e passare il tempo a controllare la compatibilità del tuo codice con la versione più recente.

Puoi anche ispirarti ad altri grandi progetti. Ad esempio puoi vedere che Programmers.SE si affida a JQuery 1.7.1, mentre il 14/09/2012 la versione più recente è 1.8.1.

Vedi anche:

• "Se non è rotto, non aggiustarlo." in Quando è SO andando ad aggiornare la loro versione jQuery?

• Motivo per utilizzare versioni precedenti di jQuery? .

Penso che abbia senso scrivere un adattatore e test (per le interfacce essenziali per la propria applicazione) affinché la dipendenza della libreria di terze parti sia in grado di adattarsi meglio alle modifiche senza timore di regressione. Questo potrebbe convincere i capi tecnici ad accettare gli aggiornamenti con meno paura. Potrebbe esserci un aggiornamento di sicurezza o un altro problema che impone un aggiornamento e sarebbe bello essere pronti per la modifica o essere in grado di cambiarne un'altra, se necessario.

Odio dirti questo, ma ha ragione. Pensavo come te, ma l'esperienza mi ha insegnato diversamente. Io e alcuni dei miei colleghi abbiamo dovuto aggiornare i framework di alcune delle nostre applicazioni web e mentre non posso dire che il framework fosse peggio, ha avuto un sacco di conseguenze impreviste che sono state la causa di diversi bug che non sono stati immediatamente resi evidenti a siamo stati scoperti dai nostri clienti.

In quel caso, dovevamo aggiornare perché avevamo bisogno di una libreria che richiedesse una versione minima delle librerie obsolete. Naturalmente, dal momento che stavamo aggiornando, abbiamo aggiornato la versione più recente (stabile) di queste librerie piuttosto che ottenere il minimo indispensabile.

Se non hai bisogno di una versione più aggiornata, non dovresti rendere il tuo codice dipendente da una base di codice in movimento. Se non vuoi avere il codice su svn, allora dovresti cercare di mantenere solo i binari di una versione specifica disponibile su svn. Meglio ancora, se usi Maven, puoi scaricare una versione specifica e tutte le sue dipendenze.

Nella mia esperienza, il modo "giusto" è da qualche parte nel mezzo. Ho avuto il piacere di lavorare su entrambi i lati radicali dello spettro, e nessuno di loro era buono.

In un progetto abbiamo avuto un lead inesperto che voleva mantenere le cose aggiornate per lo stesso motivo per cui affermi: non restare indietro nel lungo periodo. A parte il problema che dovevamo controllare il nostro codice (sebbene con una copertura di codice decente, non è un grosso problema), il problema più grande è che la libreria non viene testata dalla comunità quando viene rilasciata. Il lead del progetto è stato bruciato quando i client hanno trovato un bug nel framework che stavamo usando e, in mancanza di inviare patch al framework, non c'era nulla che potessimo fare.

Un altro progetto su cui ho dovuto lavorare è qualcosa che ricordo come probabilmente il peggior incubo della mia carriera di programmatore. I ragazzi prima di me avevano deciso che "l'aggiornamento introdurrà solo bug". Così, quando sono arrivato a metà del 2010, Hibernate aveva v2.1.0 e Maven v1.0.1, per entrambi i quali era persino un problema ricevere documentazione. È stato a quel punto che abbiamo iniziato a richiedere query SQL native (è quasi impossibile eseguire funzioni analitiche tramite Hibernate senza quella) e SQL nativo era quasi impossibile per quella versione.

Ora immagina di aggiornare una parte fondamentale di un progetto imprenditoriale di dimensioni decenti con una copertura del test quasi nullo da una versione 2004 di una struttura a una recente.

Does it really make sense to include a specific version of external library in our svn and keep using it ignoring all updates?

Dipende ...

Ho sperimentato entrambi gli approcci, e nessuno dei due ha sempre ragione, né sempre torto.

Le considerazioni principali riguardano la dinamica dell'altra libreria e quali rischi sono possibili se la libreria si aggiorna in futuro. Inoltre, quanto è critico il tuo sistema.

Le dipendenze non sono ideali e devono essere gestite con attenzione, e se si procede con l'approccio "fisso", consiglio di rivedere periodicamente lo sviluppo della biblioteca. Può essere che l'approccio migliore sia un mix di entrambi ... mantienilo fisso nel tuo sistema, ma aggiornalo occasionalmente.

Se la libreria è un componente chiave, qualsiasi aggiornamento di tale libreria potrebbe richiedere una nuova verifica del codice ... che non è auspicabile.

Le parole chiave che definiscono il tuo argomento sono "integrazione continua". È più doloroso a breve termine, ma la ragione per cui lo fai è risparmiare ancora più dolore a lungo termine. Anche se non c'è nulla di nuovo che desideri dal pacchetto in questo momento, più a lungo andrai nel futuro, più probabilmente ci sarà una funzionalità o una correzione di bug che vorresti. Quello che succede quando le persone privatamente biforcano un progetto è che ora per ottenere quella funzionalità stai tirando indietro anni di cambiamenti tutti in una volta, e potresti non avere idea di quali siano alcuni di loro. Un piccolo elenco di modifiche ogni settimana è molto più facile da gestire. Quando le persone parlano di problemi con gli aggiornamenti delle librerie di terze parti, stanno parlando degli enormi aggiornamenti, non dalla build giornaliera di ieri a quella di oggi.