Обновления.

[thesz]

Опыт достаточно давно заставил меня работать с фиксированным набором инструментов и библиотек. Это тянется ещё с... не помню. Давно. Точно помню, что я фиксировал библиотеки и компилятор при разработке на Си - я пользовался версией ТурбоСи более, чем двухлетней давности

Comments

[nponeccop]

Я только месяц назад перевёл проект с Visual Studio 2005 на более свежую. Но был и с другой стороны (жизни на нестабильных версиях). Думаю, всё завивист от того, насколько важную роль в проекте играет инструментарий, насколько инструменты стабильны и насколько активен автор инструментов. Если улучшение инструментов сушественно улучшит проект, если стоит выбор между нестабильным инструментом и отсутствием инструмента, если автор инструмента исправляет зафайленные вами баги и реализует затребованные вами фичи - то жизнь на переднем крае оправдана. А если для предметной области нет существенно облегчающих жизнь библиотек и основная масса кода - это смысловой код, а не обвязка вокруг библиотек и фреймворков - то часто переезжать на новые версии смысла нет. А в больших проектах даже раз в два года - это "часто", т.к. затраты на переезд колоссальные.

[thesz]

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

[metaclass]

Аналогично. Я обновляю версии только там, где с некоторой степенью уверенности знаю, что и как чинить.

[vozbu]

Всегда использую все самое свежее и последнее. Свежий C++11 с последним gcc, последний boost, все остальное тоже последнее. Иногда натыкаюсь на грабли, иногда на довольно серьезные, например, когда компилятор просто перестает собирать код и уже невозможно что либо выложить без срочной починки. Замораживаю версию какого-то компонента только тогда, когда выясняю, что он не работает, и до того момента, пока не починят.
Но я молодой, зеленый, мне можно ;)

[thesz]

Что за предметная область?

[vozbu]

Демоны подбора онлайн-рекламы и сопутствующая инфрастуктура статистики.

[nponeccop]

Ну тут ещё размер проекта сказывается и параноидальность "не используй несколько libc в одном процессе" (как следствие - необходимость все 10500 третьесторонних либ пересобирать при обновлениях либц). В больших проектах переезжать накладно, но в принципе, если есть культура постоянного переезда и сборка зависимостей автоматизирована - то можно.

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

[grundik]

Да так-то большинство серьёзных проектов и живёт.
И это печально.

[thesz]

Я не вижу здесь повода для печали.

[grundik]

Повод для печали в том, что даже в мире Хаскеля не получается писать библиотеки, которые можно спокойно юзать в последней версии.

При этом в других мирах ситуация осложняется тем, что новые версии обычно содержат фиксы очень неудобных багов, то есть старой ты не можешь нормально пользоваться, потому что там баги, а новой - потому что её сложно прикручивать.

Как пример - libcurl.

[thesz]

Можно использовать, можно.

Я больше про проблемы с зависимостями cabal.

[madf]

У меня ограничения версий, обычно, диктуются целевой платформой. Собственный оупенсорсный проект я до недавнего времени тестировал на gcc-2.95 и FreeBSD4 (предметная область - учет сетевого трафика). Другой проект у меня ограничен версиями библиотек в стабильной версии Debian (геодезия, GPS). В этом проекте, к стати, пара небольших подсистема написана на Haskell - обновляю библиотеки из cabal при внесении изменений в код. Выходит, примерно, раз в пол года. На работе у нас внешних библиотек практически нет, а компилятор обновляют примерно раз в год. Сейчас, вот, ведутся разговоры про gcc-4.7, но не хватает времени.
Так чтобы совсем версии фиксировать - не приходилось. Хотя нет, вру. Есть еще один проект - там "заморожен" целый дистрибутив Linux (предметная область - автоматическое управление). И у меня совсем нет желания его трогать :)
Проблемы с переходом были только один раз - когда у библиотеки поменялся API. Но все решилось очень быстро и безболезненно.