Sono scioccato - e davvero sconvolto - dal numero di risposte che dicono "non aggiornare a meno che non sia necessario". L'ho fatto, e mentre è più facile a breve termine, brucia a lungo andare. Gli aggiornamenti più frequenti e più piccoli sono molto, molto più facili da gestire rispetto a quelli occasionali di grandi dimensioni, e avrai il vantaggio di nuove funzionalità, correzioni di bug e così via.
Non compro questa idea che le modifiche alle librerie siano in qualche modo più difficili da testare delle modifiche al codice. È lo stesso: stai apportando una modifica alla base di codice e devi convalidarlo prima di eseguire il commit, e in modo più approfondito prima del rilascio. Ma devi già avere dei procedimenti per farlo, visto che stai facendo cambiamenti al codice!
Se lavori in iterazioni, da due a quattro settimane, suggerirei di aggiornare le librerie una volta per ogni iterazione, da fare il prima possibile dopo l'inizio, quando le cose sono un po 'più rilassate di una semplice prima di una scadenza di iterazione e il progetto ha più capacità di assorbire il cambiamento. Ottenere qualcuno (o una coppia se si abbina la programmazione) per sedersi, controllare quali librerie sono state aggiornate e provare a riunirle singolarmente ed eseguire una ricostruzione e un test. Budget mezza giornata al giorno per ogni iterazione, forse. Se le cose funzionano, controlla le modifiche (presumo che tu mantieni le librerie nel controllo del codice sorgente, come facciamo noi: non sono sicuro di come propagare la modifica in modo controllato se non lo fai). Questo sarà ovviamente molto più semplice se hai dei test automatici che se il test è interamente manuale.
Ora, la domanda è cosa fai se un aggiornamento rompe le cose - passi del tempo a risolverlo o a lasciarlo fuori? Suggerirei di appoggiarmi a quest'ultimo; se può essere riparato in un'ora, fatelo, ma se un aggiornamento richiederà un lavoro significativo da integrare, allora lo si eleva come una propria attività di sviluppo, da stimare, stabilire una priorità e pianificare come qualsiasi altro. Le probabilità sono che a meno che non porti a qualche correzione o miglioramento molto cruciale, la priorità sarà bassa e non ci arriverai mai. Ma non si sa mai, nel momento in cui il prossimo aggiornamento aggiornativo del giorno tondo, il problema potrebbe essersi risolto da solo; anche se non lo è, almeno ora sai che c'è un roadblock sul percorso di aggiornamento, e non ti colpirà di sorpresa.
Se non stai facendo iterazioni di quella lunghezza, vorrei impostare una sorta di programma standalone per gli aggiornamenti, non più di un mese. C'è qualche altro ritmo di progetto a cui potresti legarlo, come una recensione mensile dello stato o una riunione del consiglio di architettura? Payday? La notte della pizza? Luna piena? In ogni caso, devi trovare qualcosa di molto più breve rispetto a un ciclo di rilascio tradizionale, perché provare ad aggiornare tutto in una volta ogni 6-18 mesi sarà doloroso e demoralizzante.
Inutile dire che se si fanno rami di stabilizzazione prima delle versioni, non si applicherebbe questa politica a loro. Lì, aggiorneresti solo le librerie per ottenere correzioni importanti.