Estoy sorprendido, y de hecho horrorizado, por la cantidad de respuestas aquí que dicen "no actualices a menos que tengas que hacerlo". Lo he hecho, y aunque es más fácil a corto plazo, a la larga arde como el infierno. Las actualizaciones más pequeñas y frecuentes son mucho, mucho más fáciles de administrar que las grandes ocasionales, y obtienes el beneficio de nuevas funciones, correcciones de errores, etc., antes.
No creo que esta idea de que los cambios en la biblioteca sean de alguna manera más difíciles de probar que los cambios en el código. Es lo mismo: está haciendo un cambio en la base de código y necesita validarlo antes de comprometerse, y más profundamente antes de lanzar. ¡Pero ya debe tener procesos para hacer esto, ya que está haciendo cambios en el código!
Si está trabajando en iteraciones, de dos a cuatro semanas de duración, sugeriría hacer que las bibliotecas de actualización se realicen una vez por iteración, lo más pronto posible después del inicio, cuando las cosas están un poco más relajadas que justo antes de una iteración fecha límite, y el proyecto tiene más capacidad para absorber el cambio. Pídale a alguien (o un par si hace pares de programación) que se siente, vea qué bibliotecas se han actualizado e intente incorporar cada una y ejecutar una reconstrucción y prueba. Presupuesto medio día a un día para cada iteración, tal vez. Si las cosas funcionan, verifique los cambios (supongo que mantiene las bibliotecas en control de origen, como lo hacemos nosotros; no estoy seguro de cómo propagaría el cambio de forma controlada si no). Obviamente, esto será mucho más fácil si tiene pruebas automatizadas que si las pruebas son completamente manuales.
Ahora, la pregunta es qué hacer si una actualización rompe cosas: ¿pasa tiempo reparándola o la deja de lado? Sugeriría inclinarse hacia este último; si puede arreglarse en una hora, hágalo, pero si una actualización va a requerir un trabajo significativo para integrarse, créelo como su propia tarea de desarrollo, para ser estimado, priorizado y programado como cualquier otro. Lo más probable es que, a menos que traiga alguna solución o mejora crucial, la prioridad será baja y nunca lo alcanzará. Pero nunca se sabe, para cuando llegue el próximo día de actualización iterativa, el problema podría haberse solucionado solo; incluso si no, al menos ahora sabe que hay un obstáculo en la ruta de actualización, y no lo sorprenderá.
Si no está haciendo iteraciones de esa longitud, establecería algún tipo de programación independiente para las actualizaciones, no más de una vez al mes. ¿Hay algún otro ritmo de proyecto al que pueda vincularlo, como una revisión mensual del estado o una reunión de la junta de arquitectura? ¿Día de paga? Noche de pizza? ¿Luna llena? Lo que sea, debe encontrar algo mucho más corto que un ciclo de lanzamiento tradicional, porque tratar de actualizar todo de una vez cada 6-18 meses será doloroso y desmoralizador.
Huelga decir que si realiza ramas de estabilización antes de los lanzamientos, no les aplicaría esta política. Allí, solo actualizaría las bibliotecas para obtener soluciones críticas.