Versionamento do Syens

O versionamento do Syens (Syens geral e SEGES) é feito 100% a partir de tag e release no GitHub. Não há marcação de versão manual fora desse fluxo: uma versão só existe porque houve uma tag e um release correspondentes no repositório.

Como saber qual versão está em produção

Cada ambiente expõe a URL /version.txt, que mostra a versão que está em produção. Exemplo:

1.116.0

Basta acessar /version.txt no ambiente (Syens geral ou SEGES) para confirmar qual versão está no ar. Como a numeração é sequencial, isso garante que todas as versões anteriores também já foram entregues.

O version.txt reflete sempre a última versão com deploy: a cada atualização, ele salta para a versão fechada no release. No exemplo abaixo, o deploy do commit a72e4b11 levou o version.txt de 1.0.0 para 1.0.1:

• Os pontos em destaque (quadrados) são os deploys: é quando o version.txt muda.
• As demais marcações são as demandas, cada uma com a versão prevista conforme o versionamento semântico (veja abaixo).

Versionamento semântico

As versões seguem o padrão de versionamento semântico, no formato MAJOR.MINOR.PATCH. A próxima versão depende do tipo da entrega. Por exemplo, se a versão atual é 3.7.15:

Tipo da entrega	Nova versão	O que muda
Correção	3.7.16	incrementa o PATCH
Nova funcionalidade	3.8.0	incrementa o MINOR
Mudança incompatível com a versão anterior	4.0.0	incrementa o MAJOR

observação

A mudança de MAJOR é um caso muito específico e deve ser discutida com os líderes do projeto.

Como a numeração é sequencial, para saber o que entrou basta olhar o intervalo entre a última versão e a nova:

• (>=3).y.z — ex.: 4.y.z, 5.y.z, 6.y.z, …
• 3.(>=7).z — ex.: 3.8.z, 3.9.z, 3.10.z, …
• 3.7.(>=15) — ex.: 3.7.16, 3.7.17, 3.7.18, …

Exemplo no log do GitHub

No log do repositório, a versão é confirmada quando o líder técnico fecha o release, na atualização planejada. Uma demanda pode ter uma versão prevista (seguindo a lógica acima), mas o que vale é a tag do release. O intervalo entre dois releases mostra exatamente o que foi entregue:

• prevista X.Y.Z (ao lado da demanda): versão prevista, seguindo o versionamento semântico.
• Etiqueta vX.Y.Z (nos pontos em destaque): versão fechada no release (tag no GitHub), com deploy realizado.

No exemplo, mesmo que uma demanda tenha sido prevista como correção (2.23.2) e o release fechado seja de nova funcionalidade (v2.24.0), basta olhar o intervalo entre v2.22.13 e v2.24.0 para saber tudo o que foi entregue.

No GitHub, cada release traz um changelog gerado automaticamente — a lista de PRs em "What's Changed", mais o link de comparação com o release anterior. É esse changelog que registra o que entrou em cada intervalo, sem precisar montar a lista à mão.

Atualização planejada

O fechamento de versão acontece duas vezes por semana, sempre no primeiro horário de segunda-feira e quarta-feira (quando há novos commits, ou seja, demandas entregues). Nesse momento, um líder técnico cria a tag e o release no GitHub, preenchendo a versão adequada conforme o tipo das demandas entregues. A tag usa o prefixo v (ex.: v1.116.0).

Atualização imediata

Casos especiais — como hotfixes (correções emergenciais) ou entrega de novas funcionalidades urgentes — podem ter deploys independentes, negociados diretamente com o gerente do projeto e a liderança técnica. Esse processo é chamado de atualização imediata.