Release cycle ru RU

Цикл выпуска

ASF использует обычное для C# обозначение версий в формате A.B.C.D. Версия увеличивается после выпуска текущей версии на GitHub. Каждая версия, выпущенная по сей день, доступна на GitHub, в неизменном виде, и не исчезнет со временем, поэтому всегда возможно откатиться на любую из них, без необходимости делать свои копии.

В целом формат версии ASF очень прост - мы используем числа от 0 до 9 в позициях A, B, C и D. При смене версии увеличивается D, если новое D будет равно 10, мы вместо этого увеличиваем C и возвращаем D в 0, и так далее. Выпуск новой версии должен считаться вехой в разработке ASF, версией с реализацией заданного набора функций и готовой для тестов/использования, и не имеющей регрессий относительно предыдущей версии. Иногда мы можем посчитать что внесённые изменения очень важны, и вне очереди увеличить C, B или даже A, хотя это происходит редко (и обычно означает потерю совместимости).

Выпуски ASF делятся на две категории - стабильные (stable) и предварительные (pre-release).

Стабильные выпуски должны корректно работать и не иметь известных регрессий (на момент выпуска) в сравнении с предыдущими версиями. Мы стараемся выпускать стабильные версии либо после более длительного тестирования предварительных версий, либо как версии которые исправляют ошибки предыдущей стабильной версии, не внося новых. В очень редких случаях (как например изменения в Steam, нарушающие совместимость) мы может решить выпустить новую стабильную версию как можно быстрее, если это необходимо. Но в основном эти версии должны работать очень хорошо, поскольку мы не отмечаем стабильными версии если они имеют качество ниже, чем у предыдущего стабильного выпуска. Разумеется, это "качество" оценивается в основном по обратной связи от пользователей, которую мы получаем во время предварительной разработки, поэтому, к сожалению, возможна ситуация когда какие-то ошибки не будут обнаружены и попадут в стабильны выпуск, просто потому что на этапе разработки никто с ними не столкнулся. К счастью для нас такое случается крайне редко, и мы стараемся исправлять такие ошибки как можно скорее, в следующем стабильном выпуске.

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

Предварительные версии обычно должны работать так же хорошо, как и стабильные, и единственное отличие между ними - это то, что их тестирует большее количество пользователей. Это связано с тем, что ASF - проект с плавающим релизом, то есть его можно собрать и использовать в любой момент времени, а присваивание версий делается просто для вашего удобства, чтобы отметить изменения от одной версии к другой. Однако, если вы решите использовать предварительные версии, от вас ожидается что вы несколько более продвинутый пользователь, поскольку предварительные версии - это промежуточные этапы разработки, и возможна ситуация что хотя на вид всё работает нормально, есть вещи, которые работают неправильно и не проверены - стоит отслеживать разработку ASF на GitHub и внимательно читать списки изменений, это тот минимум, которых необходим для использования предварительных версий (для вашего же блага). В добавок к этому, бывает что мы активно тестируем что-то конкретное, как например изменения в конфигурации, переписанный код какой-то части или изменения в ядре. Всегда читайте списки изменений, поскольку такие предварительные версии могут быть более нестабильные, чем остальные.

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

Разумеется, недостаток документации относится только к предварительным версиям - у каждой стабильной версии должен быть полный список изменений и документация в wiki на момент выпуска.

После некоторого времени предварительная версия может считаться стабильной. Это особенно верно, если за это время не было внесено новых изменений, и нет смысла увеличивать версию только ради стабильного выпуска. Это также часто случается если предварительная версия считается "кандидатом для стабильного выпуска" ("RC"), поскольку это позволяет продвинутым пользователям протестировать её перед тем как отметить её стабильной, поэтому риск появления ошибок намного ниже, поэтому это наиболее распространённая схема выпусков ASF:

Stable 1.0 -> Pre 1.1 -> Pre 1.2 -> ... -> Pre 1.7 (RC) -> Stable 1.7 (то же что и Pre 1.7)

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

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

Проект ASF использует возможности и непрерывной интеграции и тестирования двумя независимыми службами - AppVeyor, который проводит тесты ASF для Windows, и Travis, который проводит тесты ASF на Linux и OS X. Каждая сборка должна быть воспроизводимой, поэтому не должно быть проблемой взять исходный код (включенный в выпуск) нужной версии и скомпилировать его самостоятельно, получив точно такой же исполняемый файл.

Дополительно, помимо стабильных и предварительных сборок ASF, вы можете также найти последние автоматические сборки AppVeyor, расположенные тут, которые обычно собираются из последних, ещё не вошедших в последнюю версию, коммитов. Из-за того, что они собираются автоматически, и не протестированы должным образом, эти сборки НЕ поддерживаются никоим образом, и обычно полезны только для разработчиков, которые хотят получить текущий образ ASF на GitHub в объектной форме, без необходимости компилировать самостоятельно. Нет никаких гарантий, что ASF в состоянии master будет правильно работать. В редких случаях, эти сборки также могут использоваться для проверки что какой-то коммит действительно исправил конкретную проблему или ошибку, не дожидаясь пока это изменение попадёт в предварительную версию. Если вы решите использовать эти автоматические сбоки, убедитесь что обладаете достаточными знаниями об ASF, поскольку "уровень" ошибок в этих сборках максимальный. Если у вас нет какой-то странной проблемы, обычно вам достаточно использовать предварительные сборки чтобы быть на острие атаки - сборки AppVeyor предоставлены как дополнение к предварительным сборкам, в основном для проверки того, что очередной коммит исправил конкретную проблему, над которой ведётся работа. Эти сборки не следует применять для реального использования.