TSP Logo TSP Wiki
Docs
TSP Wiki

    Software Versioning

    Software versioning is the process of numbering different releases of a particular software program for both internal use and release designation. It allows programmers to know when changes have been made and track changes enforced in the software.

    At the same time, it enables potential customers to be acquainted with new releases and recognize the updated versions.

    Some of the most common methods of software version numbering are:

    1. Semantic Numbering – Three-digit numbering technique based on Major.Minor.Patch
    2. Date-of-Release – The software version number is the date of the release. For example, 20.06 (June 2020)
    3. Alphanumeric Codes
    4. Sequential Numbering
    5. Unary Numbering

    What is semantic versioning?

    Semantic versioning is one of the most common methods of numbering software versions. A specific version number is in the form Major.Minor.Patch[-Suffix]. When a major, minor, or patch update is made, the corresponding number is increased.

    • Major: A significant code change that might be incompatible with previous versions, such as a fundamental change of framework.

      For example, while a 2.1.4 version would likely be compatible with a 2.2.1, it may not be compatible with a 3.0.0 or higher.

    • Minor: Significant bug fixes are implemented, or a new feature is added, but backwards compatible.

      For example, a 2.1.4 version will still be compatible with 2.2.0.

    • Patch: Backwards compatible minor bug fixes only

    • -Suffix (optional): a hyphen followed by a string denoting a pre-release version (following the Semantic Versioning or SemVer 1.0 convention ).

    The version number is increased by one digit, depending on the type of changes made in the new versioning.

    For example, software version 1.3.1 means that the software is in its first major version, with three additional functionalities added, and one patch fix implemented. When a developer fixes a bug in that version, the next version release is named version 1.3.2.

    Pre-release versions

    In addition to having versions by numbers, we can add a classification for project stability. The options we have for this are: -alpha, -beta, -rc.

    • -alpha

      The alpha’s build of the software is the build to the internal software testers, that is, people different from the software engineers, sometimes to the public, but usually internal to the organization or community that develops the software. In a rush to market, more and more companies are engaging external customers or value-chain partners in their alpha testing phase. This allows more extensive usability testing during the alpha phase.

      In the first phase of testing, developers generally test the software using white box techniques. Additional validation is then performed using black box or gray box techniques, by another dedicated testing team, sometimes concurrently. Moving to black box testing inside the organization is known as alpha release.

      In software testing terminology alpha testing is done by the client in the presence of the tester or developers and the test environment is not open for the end user.

    • -beta

      “Beta” is a nickname for software which has passed the alpha testing stage of development and has been released to users for software testing before its official release. It is the prototype of the software that is released to the public. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.

      A “beta version” is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing. The process of delivering a beta version to the users is called beta release. Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.

      The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software. They receive the software for free or for a reduced price but act as free testers.

      Beta versions test the supportability of the product, the go-to-market messaging (while recruiting Beta customers), the manufacturability of the product, and the overall channel flow or channel reach.

    • -rc

      The term release candidate (RC) refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage of product stabilization (read QA cycle), all product features have been designed, coded and tested through one or more Beta cycles with no known showstopper-class bug.

    Example

    1.1.0
1.1.1 // The highest stable version.
1.1.2-alpha
1.1.2-beta
1.3.0-beta // The highest version including the not stable versions.

    Best Practices for Software Versioning

    1. New projects start at version 0.1.0
      • You are starting with a set of features, not bug fixes.
      • Increment the minor version for each subsequent release.
    2. Start versioning at 1.0.0 if:
      • Your software is already used in production.
      • Other users depend on your software and care when the API changes.
      • You are worrying about backwards compatibility.
    3. The initial development phase is represented by Major version 0.
      • Make as many breaking changes as you want before version 1.0.0
    4. Once you have released version 1.0.0, API adjustments or other breaking changes are not acceptable without a new Major version change.
    5. If you are adding new features without breaking the existing API or functionality, increment the Minor number.
    6. If you are fixing bugs, increment the Patch number.

    References

    Edit this page on Gitlab