Я потрясен - и действительно потрясен - количеством ответов здесь, говорящих «не обновляйте, если вам не нужно». Я сделал это, и хотя в краткосрочной перспективе это легче, в долгосрочной перспективе он горит как ад. Более частые, более мелкие обновления намного проще управлять, чем случайные крупные, и вы быстрее получаете преимущества новых функций, исправлений ошибок и т. Д.
Я не верю в то, что изменения в библиотеке как-то сложнее проверить, чем изменения кода. Это то же самое - вы вносите изменения в кодовую базу, и вам нужно проверить это перед фиксацией, и более тщательно, перед тем как выпустить. Но у вас уже должны быть процессы для этого, так как вы вносите изменения в код!
Если вы работаете в итерациях, продолжительностью от двух до четырех недель, я бы предложил сделать обновление библиотек один раз за итерацию, чтобы это было сделано как можно скорее после начала, когда дела немного более расслаблены, чем непосредственно перед итерацией. срок, и проект имеет больше возможностей для принятия изменений. Попросите кого-нибудь (или пару, если вы занимаетесь парным программированием) сесть, посмотреть, какие библиотеки были обновлены, и попробовать собрать каждую из них и запустить пересборку и тестирование. Бюджет от полдня до дня для него каждая итерация, наверное. Если что-то работает, проверьте изменения (я предполагаю, что вы держите библиотеки в управлении исходным кодом, как мы делаем; я не уверен, как вы будете распространять изменения контролируемым образом, если нет). Очевидно, это будет намного проще, если у вас есть автоматические тесты, чем если тестирование полностью ручное.
Теперь вопрос в том, что вы делаете, если обновление ломает вещи - вы тратите время на его исправление или упускаете его? Я бы предложил склоняться к последнему; если это можно исправить в течение часа, сделайте это, но если обновление потребует значительных усилий для интеграции, то поднимите его как свою собственную задачу разработки, чтобы оценить, расставить приоритеты и запланировать, как и любое другое. Скорее всего, если это не принесет какого-то очень важного исправления или улучшения, приоритет будет низким, и вы никогда не сможете его обойти. Но вы никогда не знаете, что к тому времени, когда наступит следующий итеративный день обновления, проблема, возможно, решится сама собой; даже если нет, по крайней мере теперь вы знаете, что на пути обновления есть препятствие, и оно не застигнет вас врасплох.
Если вы не выполняете итерации такой длины, я бы установил какой-то отдельный график обновлений - не дольше, чем раз в месяц. Есть ли какой-то другой ритм проекта, к которому вы могли бы привязать его, например, ежемесячный обзор состояния или заседание совета по архитектуре? Payday? Пицца ночью? Полнолуние? Как бы то ни было, вам нужно найти что-то намного короче, чем традиционный цикл выпуска, потому что попытка обновлять все за один раз каждые 6-18 месяцев будет болезненной и деморализующей.
Само собой разумеется, что если вы делаете стабилизационные ветки перед выпусками, вы не примените к ним эту политику. Там вы только обновите библиотеки, чтобы получить критические исправления.