Re[4]: Версионнинг очень больших баз кода
От: Miroff Россия  
Дата: 19.04.22 09:26
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.


Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?

vsb>А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.


А тестировать эти фиксы кто будет? Владелец библиотеки? Так у него в чужом коде компетенции нет, он не знает что там и почему. Владелец кода? А ему это зачем, у него свои планы по разработке,
внезапные апгрейды библиотеки туда не входят. И как это сочетается с жизненным циклом проекта? У тебя пасхальный релиз завтра, а какие-то клоуны из соседней команды ломают твой код своими апдейтами. Или апдейты приезжают не в мастер, а в ветку? Кто тогда отвечает за то чтобы эта ветка была смерджена в мастер?

С версиями как раз все просто, старая версия объявляется устаревшей, назначается план поддержки на какой-то срок, все пользователи включают миграцию в планы разработки и за несколько месяцев без суеты переезжают.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.