TL;DR:
2026.1.100— Year.Month.Build. One number to increment. Zero entropy.
┌─────────────────────────────────────────────────────────────┐
│ OFFICIAL (public): 2026.1 │
├─────────────────────────────────────────────────────────────┤
│ CARGO VERSION (all): 2026.1.100 │
│ └── YYYY.MM.BBB - bump BBB (100→101→102) per release │
├─────────────────────────────────────────────────────────────┤
│ BUILD DNA: 2026-01-01T00:00:00.000000000Z │
│ └── Unique per compile, nanosecond precision │
└─────────────────────────────────────────────────────────────┘
| Component | Format | Example | Purpose |
|---|---|---|---|
| Official | YYYY.MM |
2026.1 |
Public-facing, marketing, docs |
| Cargo | YYYY.MM.BBB |
2026.1.100 |
All Cargo.toml, crates.io compatible |
| Build DNA | ISO-8601 ns | 2026-01-01T00:00:00.000000000Z |
Unique build identification |
# First release of January 2026
version = "2026.1.100"
# Second release same month
version = "2026.1.101"
# February 2026 arrives
version = "2026.2.100"Why start at 100? Cargo/semver rejects leading zeros (
2025.12.000is invalid). Starting at 100 preserves the 3-digit aesthetic while staying semver-compliant. We "lose" 100 slots per month — but 900 releases/month is still plenty.
| Scheme | Decisions | Bits/Release | Sync Overhead | Total Entropy |
|---|---|---|---|---|
| SemVer (x.y.z) | major/minor/patch? | ~1.58 bits | mental model | ██████████░░░░░░ 62% |
| CalVer YYYY.MM.DD | none (date-locked) | 0 bits | calendar sync | ████████░░░░░░░░ 50% |
| Dual (DD + BBB) | which scheme? + maintain 2 | ~2.0 bits | dual tracking | █████████████░░░ 85% |
| Unified YYYY.MM.BBB | just increment BBB | 0 bits | none | ███░░░░░░░░░░░░░ 18% |
╔══════════════════════════════════════════════════════════════════════════════╗
║ ENTROPY COMPONENTS ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ ║
║ SEMVER (1.2.3) ║
║ ├─ Semantic judgment: "breaking? feature? fix?" log₂(3) = 1.58 bits ║
║ ├─ Cross-package sync: "all at same version?" +0.5 bits ║
║ ├─ No temporal meaning: "when was 1.2.3?" +0.3 bits (lookup) ║
║ └─ TOTAL: ████████████░░░░░░░░ 62% ║
║ ║
║ CALVER YYYY.MM.DD ║
║ ├─ Date lookup: "what day is it?" 0 bits (automatic) ║
║ ├─ Locked to calendar: can't do 2nd build/day +1.0 bit (constraint) ║
║ ├─ Day implies staleness: "27th? it's the 28th!" +0.5 bits (perception) ║
║ └─ TOTAL: ████████░░░░░░░░░░░░ 50% ║
║ ║
║ DUAL SCHEME (DD internal, BBB for crates.io) ║
║ ├─ Two mental models running parallel +1.0 bit ║
║ ├─ "Which scheme for this package?" log₂(2) = 1.0 bit ║
║ ├─ Sync between schemes +0.5 bits ║
║ ├─ Explain to contributors +0.7 bits ║
║ └─ TOTAL: █████████████████░░░ 85% ║
║ ║
║ UNIFIED YYYY.MM.BBB (current) ║
║ ├─ Increment BBB on release 0 bits (mechanical) ║
║ ├─ All packages same scheme 0 bits (no choice) ║
║ ├─ Build DNA handles uniqueness 0 bits (automatic) ║
║ ├─ Month boundary: reset to 100 +0.18 bits (rare) ║
║ └─ TOTAL: ███░░░░░░░░░░░░░░░░░ 18% ║
║ ║
╚══════════════════════════════════════════════════════════════════════════════╝
| Action | SemVer | CalVer DD | Dual | Unified |
|---|---|---|---|---|
| "What version next?" | 🤔🤔🤔 | 📅 | 🤔🤔 | ➕1 |
| "Multiple builds today?" | ✅ | ❌ | ✅ | |
| "Same scheme everywhere?" | ✅ | ✅ | ❌❌ | ✅ |
| "Feels fresh tomorrow?" | ✅ | ❌ | ✅ | |
| "crates.io compatible?" | ✅ | ✅ | ✅ | ✅ |
SemVer: ██████████████████░░░░░░░░░░░░ 62% (judgment overhead)
CalVer DD: ███████████████░░░░░░░░░░░░░░░ 50% (calendar-locked)
Dual Scheme: █████████████████████████░░░░░ 85% (complexity explosion)
Unified BBB: █████░░░░░░░░░░░░░░░░░░░░░░░░░ 18% ← OPTIMAL
Winner: Unified YYYY.MM.BBB — mechanical increment, zero semantic judgment, one scheme everywhere, automatic freshness via build DNA.
// luna_core/build.rs generates at compile time:
println!("cargo:rustc-env=LUNA_BUILD_DNA={}", iso8601_timestamp);
println!("cargo:rustc-env=LUNA_VERSION={}.{:02}", year, month);pub const VERSION: &str = env!("CARGO_PKG_VERSION"); // "2026.1.100"
pub const VERSION_OFFICIAL: &str = "2026.1"; // Public-facing
pub const BUILD_DNA: &str = env!("LUNA_BUILD_DNA"); // Nanosecond timestamp
pub const VERSION_BUILD: u32 = 100; // Build counter (100-999)User sees: "lcpfs 2026.1" (clean, fresh)
Cargo uses: "2026.1.100" (semver-compatible)
Debug shows: "2026-01-01T00:00:00.000000000Z" (exact build moment)
Q: Build numbers go 100→999. What if I run out?
A: The number simply grows: 2026.1.1000, 2026.1.1001, etc. Cargo handles this fine.
That said, if you're shipping 900+ releases in a single month (30/day, more than one per waking hour), perhaps the versioning scheme isn't the problem you should be solving. Consider:
- 🔬 Are these releases being tested before shipping?
- 🎯 Is there a clear definition of "done" for each change?
- 🧘 When was your last day off?
The 3-digit BBB is a gentle reminder that releases should be deliberate, not a hard limit.
Q: Why not just use git commit hashes?
A: Commit hashes are excellent for identification but terrible for comparison. You can't look at a3f7b2c and e9d1f4a and know which is newer. 2026.1.142 > 2026.1.141 — instant, obvious, human-readable.
Q: Why reset to 100 each month instead of continuing from the previous month?
A: The month boundary reset serves as a natural "fresh start" signal. It also keeps numbers small and memorable. Nobody wants to debug 2026.1.47293.
Q: What about release candidates and pre-releases?
A: Use the build DNA. A pre-release is just a build that hasn't been tagged yet. When you're ready to release, bump BBB and tag. The DNA timestamp tells you exactly which build became the release.
Q: How do I know which build is deployed in production?
A: Check BUILD_DNA. Every binary contains its exact birth certificate down to the nanosecond:
2026-01-01T14:32:15.123456789Z
No ambiguity. No "which 2026.1.103 is this?" — there's only one build with that DNA.
Q: Why nanosecond precision? Why not microseconds or picoseconds?
A: Nanoseconds hit the hardware sweet spot:
┌─────────────────────────────────────────────────────────────────────────┐
│ PRECISION │ DURATION │ REALITY │
├─────────────────────────────────────────────────────────────────────────┤
│ Millisecond (ms) │ 10⁻³ sec │ Network latency scale │
│ Microsecond (μs) │ 10⁻⁶ sec │ SSD I/O, context switches │
│ Nanosecond (ns) │ 10⁻⁹ sec │ ← CPU clock cycle (~0.3ns) │
│ Picosecond (ps) │ 10⁻¹² sec │ Light travels 0.3mm │
└─────────────────────────────────────────────────────────────────────────┘
Modern CPUs run at 3-5 GHz — that's 3-5 billion cycles per second, or one cycle every ~0.2-0.3 nanoseconds. The OS timer (SystemTime) bottoms out at nanosecond resolution because that's what the hardware can actually measure.
Going finer would just add fake zeros:
2025-12-27T14:32:15.123456789Z← real precision2025-12-27T14:32:15.123456789000Z← picoseconds = fiction
Nanoseconds give us 10⁹ unique timestamps per second — enough to distinguish builds even if you somehow triggered two in the same clock cycle (you can't).
"But light travels 0.3mm in a picosecond — couldn't we go finer?"
Theoretically, yes. A transistor is ~5nm; light crosses it in ~17 attoseconds (10⁻¹⁸ sec). The limit isn't physics — it's that no current hardware clock can measure finer than nanoseconds. When quantum timing circuits arrive, we'll happily add more digits. Until then, nanoseconds are the honest limit.
Q: Wait — does this mean my PC is running real nanotech? Is nanotech no longer sci-fi?
A: Yes. Your CPU has billions of transistors at 5nm scale. Light crosses one in 17 attoseconds. You're running sci-fi hardware every time you compile.
And now it finally has matching software. 🌙
Minimum entropy: The best versioning scheme is the one that requires zero thought.
Every decision point is a potential bug. Every judgment call is cognitive load. The unified BBB scheme reduces versioning to a mechanical increment — leaving brain cycles for actual engineering.
Document created: 2026.1 | LunaOS Sovereign Release