hsb.horse
Há situações em que se deseja usar o timestamp de build ou deploy diretamente como número de versão, em vez de versionamento incremental. Isso é particularmente relevante para extensões Chrome, onde o valor máximo de versão é limitado a 65535, exigindo uma conversão adequada dos timestamps.
Código
type SemanticVersion = `${string}.${string}.${string}`;
function timeBasedSemanticVersion(): SemanticVersion { const now = new Date();
const major = now.getFullYear(); // Usar dois dígitos superiores para mês, dois inferiores para dia 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}`;}Exemplo de Uso
console.log(timeBasedSemanticVersion());// 2026.0214.14305 (para 14 de fevereiro de 2026 às 14:30:50)Especificação
- major: Ano (AAAA) - por exemplo, 2026
- minor: Mês e dia (MMDD) - por exemplo, 0214. Máximo é 1231, portanto dentro do limite 65535
- patch: Horas, minutos e último dígito dos segundos (hhmms) - por exemplo, 14305. Máximo é 23595, portanto dentro do limite
Tags de pré-lançamento e metadados de build não são suportados. Isso não é SemVer puro, mas sim um formato que codifica timestamps de forma legível.
Abordagens Alternativas
O problema com esta abordagem é que se o tempo retroceder durante múltiplos builds no mesmo dia, o número de versão poderia diminuir. Para gerenciamento mais estrito, considere o seguinte:
- Hash encurtado do commit git (alta unicidade mas perde informação de tempo)
- Número de build CI/CD (sequencial mas dependente de provedor)
- Combinação de data-hora e número de build
A vantagem da abordagem baseada em tempo é que o momento do build é imediatamente visível. Isso é efetivo para debugging e troubleshooting.