Il existe des cas où l’on souhaite utiliser directement l’heure du build ou du déploiement comme numéro de version, plutôt qu’un versionnage incrémental. C’est particulièrement pertinent pour les extensions Chrome, où la valeur maximale de version est limitée à 65535, nécessitant une conversion appropriée des horodatages.
Code
type SemanticVersion = `${string}.${string}.${string}`;
function timeBasedSemanticVersion(): SemanticVersion { const now = new Date();
const major = now.getFullYear(); // Utiliser les deux chiffres supérieurs pour le mois, les deux inférieurs pour le jour 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}`;}Exemple d’utilisation
console.log(timeBasedSemanticVersion());// 2026.0214.14305 (pour le 14 février 2026 à 14h30:50)Spécification
- major : Année (AAAA) - par exemple, 2026
- minor : Mois et jour (MMDD) - par exemple, 0214. Maximum 1231, donc dans la limite 65535
- patch : Heures, minutes et dernier chiffre des secondes (hhmms) - par exemple, 14305. Maximum 23595, donc dans la limite
Les tags de préversion et les métadonnées de build ne sont pas supportés. Ce n’est pas du SemVer pur, mais plutôt un format qui encode les horodatages de manière lisible.
Approches alternatives
Le problème avec cette approche est que si l’heure recule lors de plusieurs builds le même jour, le numéro de version pourrait diminuer. Pour une gestion plus stricte, considérez les options suivantes :
- Hash raccourci du commit git (unicité élevée mais perte de l’information temporelle)
- Numéro de build CI/CD (séquentiel mais dépendant du fournisseur)
- Combinaison de la date-heure et du numéro de build
L’avantage de l’approche basée sur l’heure est que l’heure du build est immédiatement visible. C’est efficace pour le débogage et le dépannage.
hsb.horse