Quando sceglieresti * non * per aggiornare una libreria di terze parti a una versione più recente?

La risposta breve è che la nuova versione potrebbe introdurre nuovi bug, come ha detto Robert Harvey nei commenti.

Per essere onesti, penso che ti stai avvicinando a questo nel modo sbagliato. Nella mia esperienza, l'approccio migliore è quello di mantenere la versione che hai. Presumibilmente, il tuo team ha già testato la versione che utilizzi e come si integra con il tuo sistema. In caso contrario, allora i tuoi clienti hanno.

Certo, quando esce una nuova versione, il tuo team dovrebbe vedere se risponde a tutti i bug che hai riscontrato, fornisce funzionalità da cui puoi trarre vantaggio o migliora le prestazioni generali. Solo dopo averlo eseguito di nuovo con i test, dovresti iniziare a usarlo.

Il problema con l'approccio agli aggiornamenti come qualcosa che viene fatto di default e fermato solo se qualcuno trova un problema è che è troppo facile rimanere negligenti nel processo di controllo. Alla fine, questo ti morderà quando una nuova versione introduce nuovi problemi.

Se mantieni la versione che hai, sai che il comportamento generale del sistema non cambierà.

Per rispondere, per prima cosa rivolgi la domanda alla necessità di aggiornare.

Se non esegui l'upgrade, con il tempo rimani bloccato su una versione obsoleta e troverai bug nel tuo sistema derivanti da bug nella libreria che sono stati corretti nelle versioni successive.

Supponendo che tu stia continuando a sviluppare il tuo sistema, e che la libreria pertinente sia di qualsiasi complessità, prima o poi varrà la pena aggiornarla. Cioè il costo del nuovo test giustifica il vantaggio dei restanti nell'ultima versione.

Quindi, potrebbe non essere necessario eseguire l'upgrade se queste ipotesi non vanno a buon fine.

cioè:.

1. Non sei attivamente la tua applicazione.
2. La libreria ha modifiche minime, forse solo modifiche a problemi specifici che conosci non sono rilevanti per te.

È più complesso che questo, come (2) sia un bersaglio mobile. Con ogni versione della libreria che viene fuori, la variazione accumulata aumenta e quindi il probabile valore (così come i requisiti di rischio e di test).

Si noti che se si ritardano l'aggiornamento per molto tempo "perché finora nessuna delle correzioni è importante per me", quindi quando si esegue l'aggiornamento si può trovare molto più difficile a causa dell'impatto accumulato.

Inoltre, potresti avere più librerie di terze parti che potrebbero richiedere aggiornamenti e test di tanto in tanto. Un approccio consiste nel rivedere e considerare l'aggiornamento di tutte le librerie di terze parti una volta l'anno (o in qualsiasi periodo) ed eseguire l'aggiornamento all'interno di un singolo progetto, consentendo un singolo test di regressione completo del sistema. Ciò potrebbe includere l'aggiornamento al compilatore o anche il funzionamento.

Infine, qualsiasi rischio in un aggiornamento sarà inverso rispetto alla quantità di test automatizzati in atto. Se hai poco (pertinente alla biblioteca) e hai bisogno di fare molti test manuali hai bisogno di più benefici per giustificare il costo dell'upgrade.

Quindi, ad esempio, l'aggiornamento di una libreria dell'interfaccia utente che richiede un nuovo test dell'interfaccia grafica è diverso dall'aggiornamento di una lib XML che legge alcuni file suscettibili di un test automatico.