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 project is powered by continuous integration process and tested by two independent services - AppVeyor which tests ASF on Windows, and Travis which tests ASF on Linux and OS X. Every build is supposed to be reproducible, therefore it should not be a problem to grab source (included in release) of given version and compile yourself receiving the same result as the one available through a binary.

As an extra, in addition to ASF stable releases and pre-releases, you can also find latest automated AppVeyor build here which is typically built from latest not-yet-included-anywhere commit. Due to automation and lack of any tests, those builds are NOT supported in any way, and typically are available only for developers that need to grab most recent ASF GitHub snapshot in object form, so they won't need to compile themselves. Nothing guarantees that ASF in master state will work properly. In rare cases, those builds can also be used for verifying if given not-yet-released commit indeed fixed particular issue or bug, without waiting for the change to land in pre-release. If you decide to use those automated builds, please ensure that you have decent knowledge in terms of ASF, as it's the highest "level" of bugged software. Unless you have a strong reason, usually you're already on the bleeding edge by tracking pre-release builds - AppVeyor builds are offered as an extra to pre-releases, mainly for verifying if given commit fixed particular issue we're working on right now. Those builds should not be used in any production environment.