Skip to main content
In modern software development, a clear versioning strategy ensures consistency, compatibility, and traceability. This guide compares two popular approaches—Semantic Versioning (SemVer) and Date-Based Versioning—demonstrated with a simple .NET console application. You’ll learn how to set up each scheme, understand their advantages, and choose the best fit for your CI/CD pipeline in environments like Azure DevOps.

​
Getting Started

Begin by creating a new .NET console app and setting an initial version: 
dotnet new console -n VersioningDemo
cd VersioningDemo
Open Program.cs and add a version field: 
using System;

namespace VersioningDemo
{
    // Version number will be updated per strategy
    static class Program
    {
        static string version = "v0.0.0";

        static void Main(string[] args)
        {
            Console.WriteLine("Hello, Azure DevOps!");
            Console.WriteLine($"Version: {version}");
        }
    }
}
Run the app to verify: 
dotnet run
# Output:
# Hello, Azure DevOps!
# Version: v0.0.0

​
Semantic Versioning (Major.Minor.Patch)

Semantic Versioning (SemVer) uses a three-part format: MAJOR.MINOR.PATCH. It’s ideal for libraries and APIs where backward compatibility matters.
  • Major: Breaking changes
  • Minor: New, backwards-compatible features
  • Patch: Bug fixes and small enhancements
Follow semver.org guidelines to maintain consistency across releases.

​
1. Incrementing Major

When you introduce breaking changes: 
static string version = "v1.0.0";

dotnet run
# Version: v1.0.0

​
2. Incrementing Minor

For new, non-breaking features: 
static string version = "v1.2.0";

dotnet run
# Version: v1.2.0

​
3. Incrementing Patch

For bug fixes or tweaks: 
static string version = "v1.2.1";

dotnet run
# Version: v1.2.1

​
Real-World Workflow

  1. Fix a bug → Patch: v1.2.1
  2. Add a feature → Minor: v1.3.1
  3. Revamp API (breaking) → Major: v2.0.0
Benefits of Semantic Versioning
  • Clear upgrade path: patch/minor safe, major breaking
  • Widely adopted by package managers (NuGet, npm)
  • Communicates intent to consumers

​
Date-Based Versioning (YYYY.MM.DD.BUILD)

Date-Based Versioning encodes the release date and a daily build counter. It’s perfect for fast-paced CI/CD workflows. 
YYYY.MM.DD.BUILD

​
Example Builds

First build on October 3, 2024: 
static string version = "2024.10.03.01";

dotnet run
# Version: 2024.10.03.01
Second build same day: 
static string version = "2024.10.03.02";

dotnet run
# Version: 2024.10.03.02
Build counter resets daily. Useful for tracking exact deploy date in high-frequency releases.
Benefits of Date-Based Versioning
  • Immediate insight into release date
  • Simplifies automated CI pipelines
  • No ambiguity about build sequence

​
Comparing Versioning Strategies

StrategyFormatUse CasePros
Semantic VersioningMAJOR.MINOR.PATCHLibraries, APIs, traditional release cyclesPredictable compatibility, standard across ecosystems
Date-Based VersioningYYYY.MM.DD.BUILDRapid CI/CD, daily deploymentsClear date tracking, easy automation

​
Choosing Your Strategy

  • Semantic Versioning
    Ideal for API-driven products and packages where compatibility communication is critical.
  • Date-Based Versioning
    Best for teams with continuous deployment, where the exact release date and order matter more than change scope.
Select the approach that aligns with your development workflow, tooling (e.g., Azure DevOps pipelines), and stakeholder requirements.

​
References

Watch Video