Release cycle

Release cycle

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, therefore 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 marked as the new stable release, at the same time opening a new monthly cycle for the next one.

Depending on amount of changes in the cycle, usually there will be a single C version dump (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 this pre-release cycle has a potential to be more unstable than usual, and should be tested carefully. Keep in mind that semver changed 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.

Version bump	Semver	Example of changes
A		Major .NET runtime change, foundation changes, breaking changes that are beyond ASF's codebase
B	Major	Minor .NET runtime change, breaking changes in ASF codebase, major code edits that go beyond minor classification
C	Minor	New monthly cycle, usually introducing new functionality, command, configuration property or other changes that do not break the existing setups
D	Patch	New pre-releases that are part of existing cycle on more significant number, critical bugfixes that introduce no code changes beyond necessary

Please note that newly introduced features and changes may 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 may contain work-in-progress code that doesn't have a final form yet, documentation may arrive at later stage of the development. Same thing applies to general changelog that may 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 a complete changelog and documentation on the wiki the moment it's being released.

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 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 a binary.