Estou chocado - e realmente chocado - com o número de respostas aqui dizendo "não atualize a menos que você precise". Eu fiz isso e, embora seja mais fácil no curto prazo, queima como o inferno a longo prazo. As atualizações menores e mais frequentes são muito, muito mais fáceis de gerenciar do que as grandes ocasionais, e você obtém o benefício de novos recursos, correções de bugs e assim por diante.
Não acredito que as alterações na biblioteca sejam mais difíceis de testar do que as alterações no código. É a mesma coisa - você está fazendo uma alteração na base de código e precisa validá-la antes de se comprometer e mais profundamente antes de lançar. Mas você já deve ter processos para fazer isso, pois está fazendo alterações no código!
Se você estiver trabalhando em iterações, com duração de duas a quatro semanas, sugiro que faça a atualização das bibliotecas uma tarefa uma vez por iteração, a ser feita o mais rápido possível após o início, quando as coisas estiverem um pouco mais relaxadas do que antes da iteração prazo e o projeto tem mais capacidade de absorver mudanças. Faça com que alguém (ou um par, se você emparelhe a programação) se sente, observe quais bibliotecas foram atualizadas e tente trazer cada uma delas e executar uma reconstrução e teste. Faça um orçamento de meio dia a um dia para cada iteração, talvez. Se as coisas funcionarem, verifique as alterações (presumo que você mantenha as bibliotecas no controle de origem, como fazemos; não sei como propagaria a alteração de maneira controlada, se não). Obviamente, isso será muito mais fácil se você tiver testes automatizados do que se o teste for totalmente manual.
Agora, a pergunta é o que você faz se uma atualização quebra as coisas - você gasta algum tempo corrigindo ou deixando de fora? Eu sugeriria inclinar-se para o último; se puder ser corrigido em uma hora, faça-o, mas se uma atualização exigir um trabalho significativo para integrar, crie-a como sua própria tarefa de desenvolvimento, a ser estimada, priorizada e agendada como qualquer outra. As chances são de que, a menos que traga alguma correção ou melhoria muito crucial, a prioridade será baixa e você nunca conseguirá contornar isso. Mas você nunca sabe que, no momento em que o próximo dia de atualização iterativa chegar, o problema pode ter se resolvido; mesmo se não, pelo menos agora você sabe que há um obstáculo no caminho da atualização e não o pegará de surpresa.
Se você não estiver fazendo iterações dessa duração, eu configuraria algum tipo de agendamento independente para atualizações - não mais que mensalmente. Existe algum outro ritmo de projeto ao qual você possa associá-lo, como uma revisão mensal de status ou uma reunião do conselho de arquitetura? Dia do pagamento? Noite de pizza? Lua cheia? Seja como for, você precisa encontrar algo muito mais curto que um ciclo de lançamento tradicional, porque tentar atualizar tudo de uma vez a cada 6-18 meses será doloroso e desmoralizante.
Desnecessário dizer que, se você fizer ramificações de estabilização antes dos lançamentos, não aplicará essa política a eles. Lá, você atualiza apenas as bibliotecas para obter correções críticas.