Do old-style version numbers still make sense?
Long before the endless scroll of release notes and automatic updates, software came packaged in physical media: floppies, CDs, DVDs. Version numbers were lovingly crafted — Version 3.5.2 meant something (at least to those of us who still remember writing it on a floppy label ;)). It signaled a hierarchy: major features, minor improvements, bug fixes. You knew exactly what you had.
Back then, if you were shipping a desktop app on CD, you couldn’t just push a micro-patch. You needed a build, a test cycle, a labeled release (Sid Player 1.2.49, anyone?). A three-part version number made sense: major.minor.patch told a coherent story.
Then came broadband, app stores, Docker containers, continuous deployment pipelines — and everything changed. Today, software updates roll out automatically, sometimes multiple times per day. Does 3.5.2 still mean much in a sea of nightly builds and daily hot-fixes?
Let me compare the old and the new world:
Hand-crafted version numbers (e.g. 2.4.7)
Pros:
- Convey structured meaning: major changes vs bug fixes.
- Easy to reference in support, documentation, or bug reports.
- Feels final, stable, versioned. Good for releases on solid media.
Cons:
- Arbitrariness in deciding what merits a version bump.
- Bottleneck: a human must decide to increment.
- Misleading in fast-update contexts: “Oh, version 2.4.8? Is it worth updating today?”
Date-based version numbers (e.g. 2025.06.20)
Pros:
- Clear timestamp: exactly when it was released.
- Scales effortlessly: daily, hourly, on-the-fly.
- Avoids ambiguity over “minor” vs “patch” — every build is traceable.
Cons:
- No structural hierarchy: can’t tell at a glance if it’s a major feature or a tiny fix.
- Slightly more verbose.
- Feels less “semantic” — you can’t infer scope from the version itself.
A possible compromise
What if we combine both? Let me propose a concatenation of major version and date, e.g. 5 – 2025.06.20.
(By the way, Apple just jumped from iOS 18 to iOS 26 — which is really nothing but the year in disguise. I’m not saying Cupertino reads this blog… ;))
Pros:
- MajorVersion indicates broad, breaking, feature-set changes.
- Date signals exactly when you shipped it.
- Updates during the same day can have additional prefixes, if necessary.
- A major bump (say,
6 – …) only happens on real, feature-heavy releases.
Cons:
- Slightly more verbose.
Why do I think this works? Because you immediately know: “Yep, still version 5, same major features as earlier builds, but built on June 20, 2025.”
It’s also flexible: keep shipping bug fixes or minor features even daily — no need to agonize over whether it’s 5.0.1 or 5.1.0 (and no more heated discussions about it either). Last but not least, it’s old-school meets modern: you keep the stability of “version 5” and gain the transparency of “built on 2025-06-20”.
Conclusion
We’ve moved from floppy-based releases, where version numbers were carefully picked, to a world of ubiquitous, atomic updates. Back then, structured numbering made sense; today, timestamps are king. But we don’t have to choose — a major-version + build-date scheme gives us both.
Whether you distribute on physical media or via container orchestrators, you get:
- Semantic hierarchy, from major version.
- Precise timing, from date-based builds.
- Simplicity, avoiding patch/minor version anxiety.
Now that software never really ends, maybe it’s time we let version numbers reflect what changed and when – without overthinking the number of dots.
Anyway, that’s my two cents. If you have strong opinions about SemVer (and who hasn’t?), I’m all ears.