Build Versioning Explained: Version Numbers, Build Numbers, and Release Traceability

Build versioning is the practice of assigning identifiers to software artifacts so teams can track code changes, test the correct package, and safely roll forward or backward during releases.

Originally published on 2009-10-06; fully revised and updated.

Build versioning in plain terms

In day-to-day delivery, teams often use both a version number and a build number. The version usually represents the release line (for example, major/minor/patch), while the build number identifies a specific packaged instance produced during CI or release preparation.

Why build versioning matters

• Supports rollback to a known working executable.
• Links bug fixes and enhancements to a specific shipped artifact.
• Improves traceability across development, QA, and release handoff.
• Makes milestone tracking clearer (internal build, release candidate, general availability).
• Preserves release history so teams can retrieve and redeploy prior packages quickly.

Typical workflow from development to release

A common process is: create a build, assign identifiers, test in QA, fix defects if needed, then promote the validated build for release while recording all metadata in release history.

flowchart TD
    A[Developer commits changes] --> B[CI creates build artifact]
    B --> C[Assign version and build number]
    C --> D[Deliver build to QA]
    D --> E{QA pass?}
    E -- no --> F[Fix defects and rebuild]
    F --> A
    E -- yes --> G[Promote as RC or GA]
    G --> H[Record release details and archive artifact]

Common numbering patterns

You will commonly see three-part or four-part identifiers. The original post used a four-part style example (3.8.0.139): the left segments represent the main release number, and the last segment acts as a build identifier linked to that release line.

Example: Windows resource version fields

For Windows binaries, version metadata is often stored in resource fields such as FILEVERSION and PRODUCTVERSION.

FILEVERSION 1,0,0,57
PRODUCTVERSION 1,0,0,57

VALUE "FileVersion", "1.0.0.57"
VALUE "ProductVersion", "1.0.0.57"Code language: CSS (css)

Example: composing a package version in CI

APP_VERSION="1.4.2"
BUILD_NUMBER="57"
PACKAGE_VERSION="$APP_VERSION.$BUILD_NUMBER"

echo "$PACKAGE_VERSION"Code language: PHP (php)

Ownership and release records

In many organizations, release engineering, configuration management, or application packaging teams maintain build/version records (module changes, release notes, artifact locations, and promotion status). Some teams keep this responsibility within development. The key requirement is a single, searchable history of what was built, tested, and released.

Best practices

• Define one versioning policy and apply it consistently across repos and artifacts.
• Never reuse build numbers for different binaries.
• Store build metadata with commit SHA, changelog, and environment details.
• Tag releases in source control and map tags to artifact repository entries.
• Automate version/build assignment in CI to reduce manual errors.
• Document when and why version segments are incremented (major, minor, patch, build).

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.