Release cycle ko KR

릴리스 주기

ASF uses common C# versioning with 4 numbers, written as A.B.C.D. Given version is always frozen, pointing to a fixed source code it was built from (bundled together with the release). We do not intend to remove any previously-published version, as long as our hosting provider (GitHub) remains fine with preserving them for indefinite future, so you can safely rollback to any of them without a need of making self-copies.

In general in terms of ASF versioning, we're doing our best to follow semver versioning of MAJOR.MINOR.PATCH on the 3 least significant numbers - B.C.D. Those three numbers are directly related to ASF's code. The most significant A number indicates changes with a scope that goes beyond ASF codebase itself, usually directly affecting the foundation of the program.

ASF as a project is aiming to have more or less one feature release per month, indicated by a bump of C number. 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 promoted to 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 should be carefully evaluated when running 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 on as-needed basis. 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.X 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.

Version bump	Semver	Example of changes
A		Major .NET runtime changes, foundation changes, breaking changes that are beyond ASF's codebase, stuff that might eat your cat
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 to existing stable releases that introduce no code changes beyond necessary

새로 도입되는 기능과 변경은 시간이 지난 후에도 위키 등에 문서화되지 않을 수도 있음을 양지하십시오. 작업중인 기능을 수정하기로 결정할 때마다 문서를 다시 작성하는 시간을 절약하기 위해 문서는 해당 기능의 최종 코드가 준비된 후에 작성됩니다. Due to the fact that pre-releases may contain work-in-progress code that doesn't have a final form yet, documentation may arrive at later stage of the development. 일반 변경사항도 동일하게 적용되어 사전 릴리스의 변경사항이 시간이 지난 후에도 없을 수 있습니다. Therefore if you decide to use pre-releases 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 a complete changelog and documentation on the wiki the moment it's being released.

한 버전과 다른 버전을 비교하는 정확한 변경사항은 GitHub의 커밋과 코드 변경을 통해 항상 제공되고 있습니다. 릴리스할때, 마지막 안정 릴리스와 현재 릴리스간의 중요한 차이점만을 문서화하는 경향이 있습니다. Such brief changelog is never a complete one, so if you'd like to see every change that happened between one version and another (such as our dependencies upgrades) - please use GitHub comparison for that.

ASF project is powered by our continuous integration process. Every build is supposed to be reproducible, so 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, as long as the systems are operative, the released binaries come directly from our CI process.