How to Version Your SaaS Releases in a Codebase?

Published at:
Author: Patryk Sagan


Versioning your releases is one of those topics that every SaaS founder eventually has to face. From my 20+ years building and running SaaS products, I’ve learned that simplicity wins – but only if your system is consistent and easy to track.


Let me walk you through my release versioning approach and explain why it works so well in real-world SaaS development. You’ll also see why versioning is crucial not just for your own clarity, but also for linking each release to your error tracking system.

Date-Based Release version visible in application's footer
Date-Based Release version visible in application's footer

Why not always use Semantic Versioning?

If you’re building libraries, gems, or APIs, then Semantic Versioning (SemVer) is the industry standard. It clearly signals breaking changes, backward-compatible features, and patches. Developers know exactly when they need to update cautiously.

But if you’re running a continuous SaaS product without planned “major versions” (like 2.0, 3.0…), semantic versioning quickly becomes artificial. That’s why I recommend a simpler approach for SaaS applications.

My Date-Based Release Versioning System

I base my versioning on year + release number:

  • First segment → Year, e.g. 2025
  • Second segment → Sequential release number, e.g. 2025.56.0
  • Third segment → Bugfixes/patches for that release, e.g. 2025.56.1

This means I always know when a release was made and in what order. It’s intuitive and helps the team immediately understand the product’s state.

Always Keep a Version File in Your Codebase

In my projects (e.g., Ruby on Rails), I keep a dedicated version file:

To read the full article, you need to be a member of the SaaS Dojo.

Please sign in or sign up to get access.