Zeitbasierte semantische Versionsgenerierung

Es gibt Situationen, in denen man den Build- oder Deployment-Zeitstempel direkt als Versionsnummer verwenden möchte, anstatt inkrementelles Versioning. Dies ist besonders bei Chrome-Erweiterungen relevant, wo der maximale Versionswert auf 65535 begrenzt ist, was eine entsprechende Konvertierung der Zeitstempel erfordert.

Code

type SemanticVersion = `${string}.${string}.${string}`;

function timeBasedSemanticVersion(): SemanticVersion {
  const now = new Date();

  const major = now.getFullYear();
  // Obere zwei Ziffern als Monat, untere zwei als Tag verwenden
  const minor = `${(now.getMonth() + 1) * 100 + now.getDate()}`;

  const hh = `${now.getHours()}`;
  const mm = `${now.getMinutes()}`.padStart(2, "0");
  const s = `${now.getSeconds()}`.slice(-1);
  const patch = `${hh}${mm}${s}`;

  return `${major}.${minor}.${patch}`;
}

Verwendungsbeispiel

console.log(timeBasedSemanticVersion());
// 2026.0214.14305 (für den 14. Februar 2026 um 14:30:50)

Spezifikation

• major: Jahr (JJJJ) - z.B. 2026
• minor: Monat und Tag (MMDD) - z.B. 0214. Maximum ist 1231, also innerhalb der 65535-Grenze
• patch: Stunden, Minuten und letzte Sekundenziffer (hhmms) - z.B. 14305. Maximum ist 23595, also innerhalb der Grenze

Prerelease-Tags und Build-Metadaten werden nicht unterstützt. Das ist kein reines SemVer, sondern eher ein Format, das Zeitstempel lesbar kodiert.

Alternative Ansätze

Das Problem bei diesem Ansatz ist, dass wenn die Zeit bei mehreren Builds am selben Tag zurückgeht, die Versionsnummer sinken könnte. Für eine strengere Verwaltung sollten Sie Folgendes in Betracht ziehen:

• Verkürzter Git-Commit-Hash (hohe Eindeutigkeit, aber Zeitinformation geht verloren)
• CI/CD-Build-Nummer (sequentiell aber anbieterabhängig)
• Kombination aus Datum-Uhrzeit und Build-Nummer

Der Vorteil des zeitbasierten Ansatzes ist, dass die Build-Zeit sofort sichtbar ist. Das ist effektiv für Debugging und Fehlerbehebung.