Sono scioccato - e davvero sconvolto - dal numero di risposte qui che dice "non aggiornare a meno che non sia necessario". L'ho fatto, e mentre è più facile a breve termine, brucia come l'inferno a lungo termine. Aggiornamenti più frequenti e più piccoli sono molto, molto più facili da gestire rispetto a quelli occasionali, e ottieni il vantaggio di nuove funzionalità, correzioni di bug e così via.
Non compro questa idea secondo cui le modifiche alla libreria sono in qualche modo più difficili da testare rispetto alle modifiche al codice. È lo stesso: stai apportando una modifica alla base di codice e devi convalidarla prima di eseguire il commit e più approfonditamente prima di rilasciare. Ma devi già disporre di processi per farlo, poiché stai apportando modifiche al codice!
Se stai lavorando in iterazioni, della durata di due o quattro settimane, suggerirei di aggiornare le librerie una volta per attività di iterazione, da eseguire il prima possibile dopo l'inizio, quando le cose sono un po 'più rilassate rispetto a poco prima di un'iterazione scadenza e il progetto ha una maggiore capacità di assorbire il cambiamento. Chiedi a qualcuno (o a una coppia se fai la programmazione di coppia) di sedersi, guarda quali librerie sono state aggiornate e prova a coinvolgerle tutte ed eseguire una ricostruzione e un test. Budget da mezza giornata a un giorno per ogni iterazione, forse. Se le cose funzionano, controlla le modifiche (presumo che tu mantenga le librerie nel controllo del codice sorgente, come facciamo noi; non sono sicuro di come propagheresti le modifiche in modo controllato se no). Questo sarà ovviamente molto più semplice se si dispone di test automatici che se il test è interamente manuale.
Ora, la domanda è cosa fai se un aggiornamento rompe le cose: passi il tempo a ripararlo o lo lasci fuori? Suggerirei di sporgermi verso quest'ultimo; se può essere risolto in un'ora, fallo, ma se un aggiornamento richiederà un lavoro significativo da integrare, quindi sollevalo come compito di sviluppo, da stimare, stabilire le priorità e pianificare come un altro. È probabile che, a meno che non apporti qualche correzione o miglioramento cruciale, la priorità sarà bassa e non ci si potrà mai aggirare. Ma non si sa mai, al momento che il prossimo giorno di aggiornamento ripetutamente scorre, il problema potrebbe essersi risolto da solo; anche se no, almeno ora sai che c'è un blocco sul percorso di aggiornamento e non ti sorprenderà.
Se non stai eseguendo iterazioni di tale lunghezza, imposterei una sorta di programma autonomo per gli aggiornamenti - non più di un mese. C'è qualche altro ritmo di progetto a cui potresti legarlo, come una revisione mensile dello stato o una riunione del consiglio di architettura? Payday? Pizza Night? Luna piena? In ogni caso, devi trovare qualcosa di molto più breve di un ciclo di rilascio tradizionale, perché cercare di aggiornare tutto in una volta ogni 6-18 mesi sarà doloroso e demoralizzante.
Inutile dire che se si eseguono rami di stabilizzazione prima delle versioni, non si applica questa politica a loro. Lì, aggiorneresti solo le librerie per ottenere correzioni critiche.