Ferramentas de CI/CD
Cole seus commits, informe a versão atual e receba uma sugestão de versão, um rascunho de changelog e um número de build.
Commits e número de versão são analisados no seu navegador. Nada é enviado, e nenhum serviço de Git ou CI é chamado.
Cole seus commits ou informe uma versão para começar.
Linhas não reconhecidas nunca bloqueiam o cálculo; esta opção só decide se elas aparecem na seção “Other” do rascunho de changelog.
Cole seus commits ou informe uma versão para começar.
Antes de criar a tag de um release, normalmente você responde três perguntas manualmente: qual é a próxima versão, o que entra no changelog e qual número de build acompanha esse release. Esta calculadora de versão de lançamento permite gerar changelog a partir de commits usando o mesmo lote de commits, calculando ao mesmo tempo a sugestão de versão e o número de build, para que os três nunca fiquem fora de sincronia.
A diferença em relação a subir a versão manualmente ou copiar linhas no CHANGELOG.md é que cada sugestão vem da análise do cabeçalho de cada commit, com a mesma gramática do nosso Conventional Commit Builder — não de um diff adivinhado nem de uma chamada a uma IA. Nada do que você cola sai do navegador, e a ferramenta nunca cria uma tag, faz push nem chama nenhuma API do Git ou de CI — ela só produz texto para você usar.
O que muda quando a versão, o changelog e o número de build vêm dos mesmos commits.
Algumas calculadoras de versão de lançamento pedem para você descrever as mudanças em texto livre e enviam isso para uma IA adivinhar o salto de versão. Esta ferramenta, em vez disso, analisa o cabeçalho de cada commit com a mesma gramática do nosso Conventional Commit Builder — a mesma entrada sempre gera a mesma sugestão, e nenhuma requisição de rede é enviada.
Uma calculadora de versão, um gerador de changelog e um gerador de número de build isolados não conhecem o resultado um do outro. Aqui, a versão sugerida alimenta diretamente o título do changelog e o marcador {version} do seu modelo de número de build, então os três permanecem sincronizados. O changelog gerado também funciona como um gerador de notas de release prontas para publicar.
Assim que o release é gerado, o painel de resultado linka direto para nossa ferramenta ENV diff, para você comparar variáveis de ambiente antes do deploy — um passo que os geradores isolados de changelog e número de build que comparamos não oferecem.
O que vale saber antes de colar seu primeiro lote de commits.
Cole as linhas do jeito que `git log --pretty=format:%s` imprime — um `type(scope)!: subject` por linha. Mensagens de commit com várias linhas, corpo ou rodapé `BREAKING CHANGE:` não são analisadas aqui; marque mudanças incompatíveis com `!` logo depois do tipo ou do escopo.
Digite a versão atual em SemVer estrito (por exemplo, 1.4.2) e edite o modelo do número de build se precisar. O modelo padrão `{version}+{yyyyMMdd}.{count}` usa a versão sugerida, a data de hoje e um contador de build que você mesmo digita — a ferramenta não tem contexto de CI de onde ler um número de build real.
Desligue a geração automática para editar vários campos antes de recalcular, e pressione Ctrl/Cmd+Enter para rodar uma vez manualmente.
O selo (maior, menor, patch ou sem mudança) mostra qual commit forçou o salto de versão — um marcador de mudança incompatível sempre vence um feat ou fix comum. Copie ou baixe o changelog, copie o número de build, ou siga o link do ENV diff antes de criar a tag.
Qualquer mudança nas entradas deixa o resultado anterior acinzentado e desativa copiar/baixar até você gerar de novo.
Ver o que não é analisadoQuatro peças que transformam um lote de cabeçalhos de commit em um rascunho de release pronto para usar.
Esta ferramenta lê linhas `type(scope)!: subject` com a mesma gramática do nosso Conventional Commit Builder, classifica o impacto de cada linha reconhecida e mantém o mais alto — um único `!` ou um único `feat` em qualquer lugar do lote já eleva o release inteiro.
Commits reconhecidos são agrupados em Breaking Changes, Features, Fixes e Other, renderizados como Markdown que você pode copiar ou baixar como CHANGELOG.md — entradas de mudança incompatível sempre aparecem primeiro.
Combine `{version}`, `{yyyy}`, `{yyyyMM}`, `{yyyyMMdd}` e um `{count}` digitado manualmente para montar qualquer formato de número de build que seu pipeline precise; marcadores desconhecidos ficam como estão e são sinalizados, em vez de somem silenciosamente.
Uma linha que não é um cabeçalho de commit válido é pulada na sugestão de versão e contada separadamente, sem interromper o cálculo inteiro — desligue “ignorar” para ainda ver essa linha na seção Other do changelog.
Os casos de borda que vale conhecer antes de colar os commits de um release real.
Respostas para o que as pessoas realmente perguntam antes de confiar em uma sugestão de versão baseada em commits.
Confira se a linha bate exatamente com `type(scope)!: subject` — falta de dois-pontos, um espaço a mais ou uma sintaxe não suportada fazem a linha inteira ficar sem reconhecer, e uma linha não reconhecida nunca entra na sugestão de versão. O número de linhas reconhecidas abaixo do resultado mostra quantas linhas foram realmente analisadas.
Edite o modelo do número de build em Opções. O modelo padrão `{version}+{yyyyMMdd}.{count}` insere a versão sugerida por esta ferramenta, a data de hoje e um contador que você mesmo digita — não existe ambiente de CI aqui de onde ler um número de build real, então `{count}` continua manual.
O número de versão (como 1.5.0) segue o versionamento semântico e é definido pelo impacto dos seus commits. O número de build é uma string separada, gerada a partir de um modelo — útil para sistemas de CI que precisam distinguir cada build mesmo quando o número de versão não muda. Ele pode incluir essa mesma versão via `{version}`, além de uma data e um `{count}` digitado manualmente.
Basta colar os commits como um cabeçalho por linha: esta ferramenta vai gerar changelog a partir de commits, agrupados por feat, fix e mudanças incompatíveis, no formato Keep a Changelog. Copie ou baixe como CHANGELOG.md em vez de transcrever manualmente.
Uma linha que não bate com `type(scope)!: subject` é simplesmente contada como “não reconhecida” e não entra no cálculo da sugestão de versão. Por padrão, “ignorar linhas não reconhecidas” está ativado, então ela também não aparece no rascunho de changelog — desligue essa opção se quiser vê-la.
Não encontrou sua resposta?
Cole seus commits, confirme a versão atual, e em segundos você tem uma sugestão de versão, um rascunho de changelog e um número de build.
Tudo roda localmente no seu navegador — sem cadastro, sem upload, e sem que nenhuma tag ou deploy seja disparado por você.
Toda a análise acontece localmente no seu navegador, e nada é taggeado ou publicado no seu lugar.