История изменений

Вот буквально вчера было. У меня в проекте есть зависимость на XML-парсер Saxon. Начиная с какого-то обновления он перестал в XSLT воспринимать HTML version=1.0. Это сделало неработоспособным кусок кода, в том числе те части, от которых нет исходника. Причем это обновление притащил не я, а оно само притащилось в результате разрешения длиннющей цепи зависимостей. Эта проблема решается написанием интерцепторов, которые ловят вызов xsl и препроцессят его ДО попадания в Saxon другим парсером, и в тэге html меняют аттрибут version с 1 на 4.

Более того, в java есть такое интересное поведение, что в зависимости от того, какие зависимости сейчас просто _существуют_, код будет работать еще более по-разному, например - отдавать объекты в совершенно другом формате. В частности, если того же Saxon нет в зависимостях, то автоматически выбирается другой XML-парсер, который отдает другой формат внутренних структур, и код мгновенно рассыпается в труху. Но иногда происходит хуже - не вылетает никаких ошибок, а код начинает просто работать по-другому, идти по другим веткам if'ов итп, выдавая другой результат (который на глаз еще фиг отличишь).

И ты оказываешься в ситуации когда и новая зависимость не подходит (не работает со старым кодом) и старая не подходит (не работает с новым кодом, который уже завязался на новые фичи), и вообще непонятно на какую версию был расчитан исходный софт, потому что судя по логу коммитов, нормально оно не должно было работать никогда.

У меня на решение всех этих проблем ушел день в отладчике, туча коммитов на интеграцию компонентов, включая декомпиляцию кусков кода которые есть только в бинарном виде (кстати совершенно непонятно, работает ли новый код так же хорошо как его бинарный аналог). Мантейнер бы эту задачу решал ну.. наверное, бросил бы на первой неделе =)

Таким образом версии зависимостей меняют алгоритм работы программы, и данные которые эта программа генерит на выходе. И из-за этого становятся областью ответственности программистов, которые должны все это отлаживать. Особенно для кода, который в зависимости от набора доступных зависимостей должен вести себя по-разному

Вот буквально вчера было. У меня в проекте есть зависимость на XML-парсер Saxon. Начиная с какого-то обновления он перестал в XSLT воспринимать HTML version=1.0. Это сделало неработоспособным кусок кода, в том числе те части, от которых нет исходника. Причем это обновление притащил не я, а оно само притащилось в результате разрешения длиннющей цепи зависимостей.

Более того, в java есть такое интересное поведение, что в зависимости от того, какие зависимости сейчас просто _существуют_, код будет работать еще более по-разному, например - отдавать объекты в совершенно другом формате. В частности, если того же Saxon нет в зависимостях, то автоматически выбирается другой XML-парсер, который отдает другой формат внутренних структур, и код мгновенно рассыпается в труху. Но иногда происходит хуже - не вылетает никаких ошибок, а код начинает просто работать по-другому, идти по другим веткам if'ов итп, выдавая другой результат (который на глаз еще фиг отличишь).

И ты оказываешься в ситуации когда и новая зависимость не подходит (не работает со старым кодом) и старая не подходит (не работает с новым кодом, который уже завязался на новые фичи), и вообще непонятно на какую версию был расчитан исходный софт, потому что судя по логу коммитов, нормально оно не должно было работать никогда.

У меня на решение всех этих проблем ушел день в отладчике, туча коммитов на интеграцию компонентов, включая декомпиляцию кусков кода которые есть только в бинарном виде (кстати совершенно непонятно, работает ли новый код так же хорошо как его бинарный аналог). Мантейнер бы эту задачу решал ну.. наверное, бросил бы на первой неделе =)

Таким образом версии зависимостей меняют алгоритм работы программы, и данные которые эта программа генерит на выходе. И из-за этого становятся областью ответственности программистов, которые должны все это отлаживать. Особенно для кода, который в зависимости от набора доступных зависимостей должен вести себя по-разному