Release cycle ru RU

Цикл выпуска

ASF использует стандартную для C# нумерацию версий из 4 чисел, записанных в виде A.B.C.D. Каждая версия всегда "заморожена" и указывает на фиксированный исходный код, из которого она была собрана (он идёт в комплекте с релизом). Мы не намерены удалять ранее опубликованные версии, во всяком случае пока наш хостинг-провайдер (GitHub) не возражает хранить их в течение неопределённого времени, поэтому вы всегда можете откатиться на любую из них без необходимости делать собственные копии.

В общих принципах присвоения версий ASF, мы стараемся следовать принципу semver МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ в трёх младших числах - B.C.D. Эти три числа напрямую связаны с кодом ASF. Самое старшее число A указывает на глобальные изменения, лежащие за пределами самой кодовой базы ASF, обычно напрямую влияющие на саму основу программы.

ASF как проект имеет целю примерно одну версию с новыми в месяц, обозначаемую увеличением числа C. In order to make such release possible, we have smaller pre-releases dedicated to advanced users, which serve as smaller milestones of changes that are released on as-needed basis when there will be enough of changes since the last pre-release to focus on. Eventually, when a final pre-release will be determined to be stable and mature enough with no known critical regressions that should be corrected compared to previous stable release, it'll be marked as the new stable release, at the same time opening a new monthly cycle for the next one.

While we're doing our best to ensure that even our pre-releases are relatively stable, it should be noted that pre-releases aren't supposed to be used in any production environment. Pre-releases might have critical bugs and otherwise broken functionality, which is exactly why we're releasing them to begin with - so we can avoid all of that mess in our stable builds and offer reliable software. If you're unwilling to accept higher risk that comes from using potentially unstable software, please avoid using our pre-release builds and stick with our latest stable build instead, which is more appropriate for majority of users.

Depending on amount of changes in the cycle, usually there will be a single C version bump (from previous stable), and D bumps for every pre-release. However, when introducing changes with far bigger scope, especially breaking changes, the cycle might start from (or switch in the middle) to B or even A bump - such switch indicates that current release cycle has a potential to be more unstable than usual, and should be tested carefully. Keep in mind that semver changes we're making relate only to previously released stable version, we do not track versioning across pre-releases in a cycle themselves, which means that version 1.0.1.2 might have a new feature that 1.0.1.1 didn't have, as long as the previously marked stable release is from 1.0.0 family. Likewise, there could be major breaking changes even across two pre-releases from the same cycle, which is especially true when we're still deciding about the final shape of newly-introduced functionality or similar.

Увеличение версии	Semver	Пример изменений
A		Major .NET runtime changes, foundation changes, breaking changes that are beyond ASF's codebase
B	Major	Minor .NET runtime changes, breaking changes in ASF codebase, major code edits that go beyond minor classification
C	Minor	New monthly cycles, usually introducing new functionalities, commands, configuration properties or other changes that do not break the existing setups
D	Patch	New pre-releases that are part of existing cycle (indicated by more significant number), critical bugfixes that introduce no code changes beyond necessary

Обратите внимание, что новые функции и изменения могут быт не документированы (например в wiki) до более позднего времени, поскольку документация обычно пишется когда готов окончательный код для данной функции (чтобы сэкономить время на переписывании документации каждый раз когда мы решим изменить функцию, над которой работаем). Due to the fact that pre-release may contain work-in-progress code that doesn't have a final form yet, documentation may arrive at later stage of the development. То же самое верно и для списка изменений, который может быть недоступен для некоторых предварительных версий до какого-то времени. Поэтому, если вы решили использовать предварительные версии - будьте готовы время от времен изучать содержимое коммитов в ASF. Of course, lack of documentation applies only to pre-releases - each stable version must always have a complete changelog and documentation on the wiki the moment it's being released.

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

ASF project is powered by our continuous integration process. Every build is supposed to be reproducible, therefore it should not be a problem to grab source (included in the release) of given version and compile yourself receiving the same result as the one available through our precompiled binaries. We typically avoid compiling releases ourselves, the released binaries come directly from our CI process.