{"id":327,"date":"2026-10-13T15:11:28","date_gmt":"2026-10-13T15:11:28","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2012\/05\/23\/versioning-in-software-configuration-management\/"},"modified":"2026-10-13T15:11:29","modified_gmt":"2026-10-13T15:11:29","slug":"versioning-in-software-configuration-management","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/versioning-in-software-configuration-management\/","title":{"rendered":"SCM Versioning Done Right: Four-Part File Versions, Build Numbers, and Safer Installers"},"content":{"rendered":"\n

Software versioning in Software Configuration Management (SCM)<\/strong> is the practice of assigning consistent versions to files and builds so teams can trace artifacts, reproduce releases, and avoid upgrade breakage. This guide is for build engineers, release managers, and developers who want a practical scheme they can enforce in CI and setup processes.<\/p>\n\n\n\n

Originally published on 2012-05-23; fully revised and updated.<\/em><\/p>\n\n\n\n

This rewrite is based on guidance attributed in the original article to The Build Master: Microsoft\u2019s Software Configuration Management Best Practices<\/em>. See the original post<\/a> for historical context.<\/p>\n\n\n\n

\"Versioning<\/figure>\n\n\n\n

Why versioning matters in SCM<\/h2>\n\n\n\n

A reliable versioning scheme helps teams answer critical questions quickly: What source produced this binary?<\/em> Can we rebuild that release?<\/em> Is this upgrade safe?<\/em> The source material highlights these operational benefits.<\/p>\n\n\n\n

  • Trace product binaries back to source and ownership.<\/li>
  • Re-create previous builds using meaningful labels or tags.<\/li>
  • Reduce component conflicts (historically called \u201cDLL hell\u201d).<\/li>
  • Support setup, upgrades, and service pack workflows.<\/li>
  • Help support and QA identify exactly which bits are running.<\/li><\/ul>\n\n\n\n

    A practical four-part file version format<\/h2>\n\n\n\n

    The original guidance recommends a four-part file version pattern:<\/p>\n\n\n

    major<\/span>.minor<\/span>.build<\/span>.revision<\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    Version fields and typical ownership<\/h3>\n\n\n\n
    Field<\/th>Typically assigned by<\/th>How often it changes<\/th>Primary purpose<\/th><\/tr><\/thead>
    Major<\/td>Component or product owner<\/td>Rarely during a release cycle<\/td>Internal product line or major release identity<\/td><\/tr>
    Minor<\/td>Component or product owner<\/td>Rarely during a release cycle<\/td>Incremental release indicator<\/td><\/tr>
    Build<\/td>Build or release automation<\/td>Every build<\/td>Uniquely identifies generated artifacts<\/td><\/tr>
    Revision<\/td>Build or servicing team<\/td>Usually during servicing<\/td>Patch, hotfix, or replacement context<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Build number strategy: incremental counters vs date stamps<\/h2>\n\n\n\n
    The source explicitly recommends a simple n = n + 1<\/strong> build number for each released build. The main reason is clarity when you have multiple releases on the same day.<\/p>\n\n\n\n
    Strategy<\/th>Example<\/th>Strengths<\/th>Weaknesses<\/th>Fit with source guidance<\/th><\/tr><\/thead>
    Incremental counter<\/td>100, 101, 102<\/td>Simple ordering, unique per build, easy rollback discussions<\/td>Needs persistent counter storage<\/td>Recommended<\/td><\/tr>
    Date-based only<\/td>20261013<\/td>Human-readable date<\/td>Ambiguous for multiple same-day builds<\/td>Not recommended<\/td><\/tr>
    Date plus suffix<\/td>20261013.2<\/td>Distinguishes same-day builds<\/td>Convention drift and parsing inconsistency risk<\/td>Use only if governance is strict<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Where versioning fits in the build and release workflow<\/h2>\n\n\n\n
    \nflowchart TD\n    A[Code merged to main] --> B[CI starts build]\n    B --> C[Build counter increments]\n    C --> D[Artifacts get version stamp]\n    D --> E[Tests run]\n    E --> F{Release approved}\n    F -- no --> G[Fix and rebuild]\n    F -- yes --> H[Publish package]\n    H --> I[Installer compares existing versions]\n    I --> J[Upgrade only when candidate is newer]\n<\/pre>\n\n\n\n
    This flow keeps source control, build identity, and deployment behavior aligned. Without this alignment, support teams lose traceability and upgrades become risky.<\/p>\n\n\n\n
    Example: stamping version values in CI<\/h2>\n\n\n\n
    The following examples show a minimal pattern: persist a build counter, construct major.minor.build.revision<\/code>, then stamp artifacts.<\/p>\n\n\n
    MAJOR=4<\/span>\nMINOR=2<\/span>\nPREV_BUILD=$(cat .ci\/build-counter)\nBUILD=$((PREV_BUILD + 1<\/span>))\nREVISION=0<\/span>\n\nVERSION=\"$MAJOR.$MINOR.$BUILD.$REVISION\"<\/span>\nprintf \"%s\\n\"<\/span> \"$BUILD\"<\/span> | tee .ci\/build-counter\nprintf \"%s\\n\"<\/span> \"$VERSION\"<\/span> | tee build\/version.txt\n\necho \"Building version: $VERSION\"<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
    steps:\n  - name: Compute version\n    run<\/span>: .\/scripts\/compute-version.sh\n  - name: Build\n    run<\/span>: .\/scripts\/build.sh \"$(cat build\/version.txt)\"<\/span>\n  - name: Publish metadata\n    run<\/span>: .\/scripts\/publish-metadata.sh \"$(cat build\/version.txt)\"<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
    # Example<\/span>: inspect<\/span> a<\/span> built<\/span> DLL<\/span> file<\/span> version<\/span>\n(Get-Item<\/span> \".\\bin<\/span>\\MyComponent<\/span>.dll<\/span>\").VersionInfo<\/span>.FileVersion<\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    Installer rules that reduce component conflicts<\/h2>\n\n\n\n
    The original article focuses heavily on setup behavior in Windows component ecosystems. The core principle is still useful: an installer must make deterministic, version-aware decisions<\/strong>.<\/p>\n\n\n\n
    • Install OS-specific and locale-specific components correctly.<\/li>
    • Avoid writing shared binaries into system directories unless performing an approved system-component update.<\/li>
    • Do not overwrite newer components with older ones.<\/li>
    • If files are in use, schedule copy on reboot to avoid mixed old\/new states.<\/li>
    • Register components correctly when registration is required.<\/li>
    • Keep recoverable backups of overwritten components when feasible.<\/li>
    • Distribute a controlled installer package rather than loose raw component files.<\/li>
    • Test setup on clean systems and on realistic machines with existing software.<\/li><\/ul>\n\n\n\n
      Best practices checklist<\/h2>\n\n\n\n
      • Define one organization-wide version format and document ownership of each field.<\/li>
      • Use a monotonic build counter for released builds.<\/li>
      • Stamp every artifact and publish version metadata with each pipeline run.<\/li>
      • Make installer overwrite logic explicitly version-aware.<\/li>
      • Test upgrade and rollback paths as first-class release criteria.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"
        Versioning in Software Configuration Management is how teams trace binaries to source, reproduce builds, and ship safer upgrades. This guide turns the original notes into a practical, modern workflow with version structure, CI stamping, and installer safeguards.<\/p>\n","protected":false},"author":1,"featured_media":3798,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[282,1122,545,244,593,397,2438,2437,2441,2440,2439,179,2435,2442,732,213,2434,2436],"class_list":["post-327","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorised","tag-configuration","tag-guide","tag-how","tag-management","tag-process","tag-scm","tag-scm-versioning-guide","tag-scm-versioning-process","tag-scm-versioning-reference","tag-scm-versioning-steps","tag-scm-versioning-tutorial","tag-software","tag-software-configuration-management","tag-software-configuration-management-versioning","tag-steps","tag-tutorial","tag-versioning","tag-versioning-in-scm"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/327","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=327"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/327\/revisions"}],"predecessor-version":[{"id":79195,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/327\/revisions\/79195"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/3798"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=327"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=327"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=327"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}