Здравствуйте, Ikemefula, Вы писали:

S>>Нет. Это должно происходить когда все остальные шаги (такие как обновления библиотек в своём проекте) предприняты и не помогла.
I> Алё — на этапе разработки ты и представить не можешь, что куда кому взбредет в голову задеплоить. Как ты собираешься проанализировать тысячу-другую возможных комбинаций?
Достаточно нескольких (2-5) популярных дистрибутивов поддерживать. Всё остальное — "мы не поддерживаем данный дистрибутив но готовы помочь за допплату"


I>>>Вероятно, это ты так видишь свою работу. Только при чем здесь другие программисты, если дело в тебе?
S>>Нет, это я так вижу работу отвечающих мне тут программистов, которые кричат о том что можно делать говно так как юзер просто купит памяти/стораджа и поэтому можно тяпляп.
I>Как я вижу, у нас есть Шеридан, который не в курсе что на этапе разработки нет сведений из будущего
I>1. кто куда чего может задеплоить
В рекомендованные вами дистрибутивы. Почемуто считается нормальным указываать версию мака и виндов для которых приложение работает. Но с линупсом надо обязательно вообще всё!!11.
Не работает так.

I>2. какие новые неизвестные баги могут быть привнесеные в какую из десятков или сотен зависимостей?
Вот это и есть — "закостеневание". Это когда "нетнет, обновляться нинада, уже и так хорошо, а вдруг там монстры??7"


I>>>Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке?
S>>Написать баг авторам либы и не переходить пока он не будет починен.
I>Бинго! И автор либы через месяц сообщает, что он пофиксит, но возможно после того, как выкатит две версии.
Автор общается, отвечает — ждём. А пока работаем со старой версией.

I>А потом заходишь ты в гитхаб либы, и видишь, что эта проблема булькает уже три последних года.
Два варианта:
1. Сменить библиотеку.
2. Форкнуть и пофиксить.
Почему так? Потому что де-факто эта либа уже не поддерживается никем. И обязательно устареет. Не сегодня так через пару лет. И всёравно придётся вот эти вот два пункта.
Я за то, чтобы запланировать один из этих пунктов и в рабочем порядке решить.
Ты за то чтобы оставить всё как есть и ждать петуха с вооот таким клювом...


I>>>К твоему сведению, в ченджлогах пишут зафикшеные баги, а не новые неизвестные.
S>>Для них есть багтрекер. Выше только что написал.
I>Похоже, что ты не различаешь "новые известные" и "новые неизвестные". Первые — в баклоге. А вот остальные булькают то тут то там и возможно не скоро попадут в баклог.
Я про новые неизвестные и пишу. Нашол такой — в багтрекер его.


I>>>Это голословно.
S>>Нет, так делают люди, у которых процесс поставлен нормально а не "и так сойдёт".
I>Шериданы что ли?
Если тебе так нравится, то да.


I>>>Наоборот. Я знаю ситуацию с обоих сторон — и как потребитель фремворка, и как разработчик.
S>>ВНЕЗАПНО, я тоже. И я знаю, что если обновления планировать и выполнять в запланированное время (хотя бы раз в квартал), то затраты сильно ниже, чем обновляться только тогда когда приходит петух со своим клювом.
I>Это какие то общие слова вида "хорошее лучше плохого".
В противовес твоему "старое лучше свежего" звучат более логично, не находишь ли?


I>>>Голословно. Любая версия либы может сломать обратную совместимость. Нет способа гарантировать отсутствие багов.
S>>Я понял, ты теперь прицепился к возможным багам и не отцепишся. Багтрекер, друже, бааагтрееекер.
I>Что бы баг попал в багтрекер, его ктото должен обнаружить, идентифицировать, подготовить описание, стабильную последовательность. До того этот баг будет просто булькать тут и там и подламывать разработку.
Ты и твоя команда это будут делать. Ты и твоя команда. В рабочем порядке во время запланированного обновления используемых либ на этапе тестирования свежего перед принятием решения "обновляться можно уже сейчас или ещо подождать?".