BombusLime disclaimer

Увы, но у подавляющего большинства начинающих пользователей, пожелавших по какой-либо причине “попробовать ночную сборку” (а то и “пересесть” на неё), есть серьёзное непонимание того, что такое “альфа версия” применительно к разработке программного обеспечения и под чем вы “подписываетесь”, начиная использовать версию, находящуюся в разработке. Сюда же относятся вопросы в стиле “как мне получить ночную сборку???”, которые обычно остаются неотвеченными в конференции BombusLime.

Итак, в начале — основа-основ: “зрелое” программное обеспечение обычно разрабатывается циклически, путём повторения трёх этапов:

1. Добавление новой функциональности (новых “фич”), улучшение старой. Самый главный и самый длинный период. Обычно про ПО, находящееся на этом этапе разработки, говорят, что оно “в альфа версии”. Код в данном состоянии предназначен для “обкатки” только разработчиками и очень опытными пользователями.
2. “Заморозка” следует после того, как ведущий (”мейнтейнер”) проекта принял решение выпустить следующую стабильную версию. На этом этапе новая функциональность не добавляется (за исключением тривиальных вещей), только исправляются найденные ошибки. Обычно в этот период выпускается несколько “бета” версий, предназначенных для тестирования широкой публикой.
3. Выпуск. После того, как ведущий проекта считает, что все очевидные ошибки найдены и исправлены, следует выпуск (”релиз”) новой стабильной версии ПО.

Применительно к BombusLime, эти три стадии определяют три варианта “доступности” BombusLime для использования:

Код официально доступен только через репозиторий.

Код доступен в виде стандартных архивов с “бета версиями”; они содержат то, что обычно (не совсем верно) называется “исходниками BombusLime”.

Код доступен в виде “архива с исходниками”; он является единственной “референсной” формой распространения BombusLime. Однако разработчики BombusLime обычно выпускают BombusLime в виде специальных установщиков, предназначенных для удобного использования BombusLime на конкретных системах и пригодных даже для совершенно неопытных пользователей.

Настало время поподробнее остановиться на “нестабильной версии”, которая “живёт” в репозитории системы управления версиями GIT.

Существует несколько мифов и непониманий, связанных с нестабильной версией BombusLime.

Во-первых, несмотря на то, что BombusLime разрабатывается таким способом, что “голова” репозитория обычно вполне работоспособна, иногда туда вносятся баги. Иногда это весьма серьёзные баги, которые вполне могут приводить к частичной потери работоспособности BombusLime до тех пор, пока баг не будет исправлен. Непонимание того, что “нестабильная” версия в любой момент “вдруг” может оказаться неработающей — одна из главных проблем начинающих. Причем проблемы могуть быть самыми разными. Например, в одночасье может быть изменена система хранения протоколов чата, а код для автоматической конвертации старого формата в новый ещё не будет написан.

Посему совершенно неправильным является отношение к репозиторию просто как к неудобному (или, наоборот, удобному) способу получать новую функциональность в BombusLime. Если что-то ломается, вы оказываетесь предоставлены сами себе.

Во-вторых, если вы не разработчик, и если вы, прочитав первый пункт, согласны быть “подопытным кроликом” (а наличие таких пользователей на самом деле весьма важно для разработчиков), вы принимаете на себя ответственность действовать по определённой схеме. Самое главное: вы обязательно должны читать логи коммитов в репозиторий или файл ChangeLog — без этого вы становитесь мишенью для несуществующих багов: изменившуюся функциональность или её конфликт со старыми настройками, плагинами и чем угодно ещё вы воспринимаете как баг и тратите время разработчиков на ковыряния с вашей проблемой.

Итак, подытожим: чтобы следить за нестабильной версией и помогать разработчикам выявлять ошибки, вы должны:

1. Знать матчасть. В нашем случае это означает:
   1. Понимание принципа работы систем управления версиями и принципа работы GIT; в частности, вы должны совершенно чётко представлять себе, что происходит, когда вы делаете git pull и что означают сообщения клиента в ходе выполнения этой операции.
   2. Умение “откатывать” версию вашего рабочего каталога назад, если вы наткнулись на баг в свежем коммите, который препятствует вашей нормальной работе с BombusLime.
2. Читать логи изменений в обязательном порядке. Сопоставлять наблюдаемые вами изменения в работе, проблемы BombusLime с этой информацией.
3. Уметь сообщать о багах так, чтобы разработчикам было понятно, о чём идёт речь.

Изучить матчасть поможет свободно доступная книга по GIT (переведённая, между прочим, на русский). Если же всё изложенное — не для вас, не мешайте разработчикам разрабатывать и “вкладывайтесь” в тестирование на другой стадии — на стадии “пререлиза”, о которой рассказано ниже.

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

Беты, как правило, не содержат очевидных проблем, и их использование относительно безопасно для ваших нервов.

Тестирование пререлизных версий очень полезно для продукта. Имейте в виду, что проблемы в уже выпущенной стабильной версии свободного ПО — это проблемы, прежде всего, самих пользователей, так как за разработчиками редко стоит некая организация, способная организовать систематическое тестирование (при помощи оплаченной команды специалистов). Так что если вы хотите быть уверены, что стабильная версия будет работать так, как надо, тестируйте её бета-версии.

Понятно, что в мире free software (и в мире проприетарного ПО, кстати, тоже) никто никому ничего “по настоящему” не обязан и ничего не должен. Здесь мы имеем в виду чисто “социальные” и моральные обязательства, которые влечёт за собой участие в программном проекте.

Не секрет, что “ночная” сборка BombusLime довольно-таки стабильна (если только не находится в процессе активной разработки), поэтому при желании можно и рыбку съесть, и на ёлку влезть, то бишь и свежую версию поюзать, и по большей части избежать сопряжённого с этим геморроя.

Based on Tkabber Wiki