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 - проект с плавающим релизом, то есть его можно собрать и использовать в любой момент времени, а присваивание версий делается просто для вашего удобства, чтобы отметить изменения от одной версии к другой. Still, if you decide to use pre-releases, you should typically be a bit more advanced user, as pre-releases are usually work-in-progress smaller ASF milestones, and it's totally possible that even if something seems to be working decent, it might have stuff that isn't necessarily working or tested yet - tracking ASF development on GitHub and carefully reading changelogs is the minimum that you must do if you want to use pre-releases (for your own good). In addition to that, there are moments when we're actively testing something specific, such as configuration change, new rewritten code for given thing, or core changes. Always read changelog in this case, as such pre-release version might be more unstable than other ones.

Please note that newly introduced features and changes might be undocumented (e.g. on the wiki) until some time later, as documentation is usually written once final code of given feature is ready (to save us time rewriting documentation each time we decide to modify the feature we're currently working on). Due to the fact that pre-release might contain work-in-progress code that doesn't have a final form yet, documentation might arrive at later stage of the development. Same thing applies to general changelog that might be unavailable for given pre-release until some time later. Therefore if you decide to use pre-release then be prepared for looking inside ASF commits from time to time.

Of course, lack of documentation applies only to pre-releases - each stable version must always have complete changelog and documentation on the wiki the moment it's being released.

A pre-release version might be considered stable after some time. This is especially true if there are no changes done in the meantime, and there is no point in version bump just for the sake of stable release. It's also done very often when pre-release is considered "stable release candidate", as it allows advanced users to test it before it gets marked as stable, so the risk of introducing bugs is much lower, therefore this is the most common pattern when it comes to ASF releases:

Stable 1.0 -> Pre 1.1 -> Pre 1.2 -> ... -> Pre 1.7 (RC) -> Stable 1.7 (same as Pre 1.7)

In general though, ASF releases are being released when they're ready, which results in non-predictable release schedule. Usually there is a pre-release at the end of any major feature or change being done, and a stable release if no bugs are found after some time (a few days) since pre-release became available. We're aiming for more or less one stable release per month, unless there are some critical issues to deal with or likewise. Pre-releases are happening on as-needed basis when we feel like there is enough of stuff that needs to be tested since the release of the last one. Depending on how busy ASF development is in given moment, this can be from a few to a dozen of pre-releases between each stable release.

The precise changelog that compares one version to another is always available on GitHub - through commits and code changes. In release we tend to document only changes we consider important between last stable and current release. Such brief changelog is never a complete one, so if you'd like to see every change that happened between one version and another - please use GitHub for that.

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.