# Padrao Versionamento

> Define a política customizada de versionamento semântico da aplicação (Major.Minor.Patch)

- Skill: `moisesfilho/padrao-versionamento` (Agent Skill)
- Install (CLI): `npx skillmds@latest add moisesfilho/padrao-versionamento`
- Raw SKILL.md: https://api.skillmd.com/api/skills/moisesfilho/padrao-versionamento/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: moisesfilho (https://skillmd.com/u/moisesfilho)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/moisesfilho/padrao-versionamento

---


Goal:
Garantir que a versão da aplicação siga a estratégia comercial (Major fixo/manual) e incremente os números menores de forma consistente de acordo com as entregas e estratégias de branch.

Instructions:
1. Formato: O projeto usa o formato MAJOR.MINOR.PATCH (ex: 1.2.0).
2. Major (X.0.0): Representa o primeiro dígito (da esquerda). Esse número **só deve ser alterado manualmente** pois é controlado por estratégias comerciais. Não incremente o Major automaticamente sob nenhuma circunstância.
3. Minor (0.X.0): Representa o segundo dígito (do meio). Deve ser incrementado sempre que uma **nova funcionalidade** for desenvolvida (equivalente a commits do tipo `feat:`). Lembre-se: ao incrementar o Minor, o número Patch deve voltar para zero (ex: de `1.2.5` para `1.3.0`).
4. Patch (0.0.X): Representa o terceiro dígito (da direita). Deve ser incrementado sempre que uma **correção de bug** (`fix:`), uma **melhoria** (`refactor:`, `perf:`) ou outra alteração menor (`chore:`, `style:`) for aplicada (ex: de `1.2.0` para `1.2.1`).
5. Onde Atualizar: No Android, a versão da aplicação reside no arquivo `app/build.gradle.kts` nos campos `versionName` (ex: "1.5.0") and `versionCode` (inteiro, incrementado a cada novo build).
15. Branches de Feature: Quando um novo branch de feature for criado (ex: `feature/*`), **não é necessário incrementar a versão** (tanto `versionCode` quanto `versionName` permanecem os mesmos herdados da branch de origem).
16. Criação de Release Candidate (RC - Testes Internos): O envio para teste interno e o incremento da versão da aplicação **só devem ocorrer quando uma branch de release candidate for criada** (ex: `release/*` ou `rc/*`) a partir da branch `develop`. Nesse momento, o `versionCode` e `versionName` devem ser incrementados de acordo com a natureza das mudanças (Minor ou Patch) e a versão deve conter obrigatoriamente o sufixo **`-alpha`** (ex: `1.6.0-alpha`).
17. Merge na main (Produção): Quando uma branch de release candidate for integrada (mergeada) de volta para a branch **`main`**, a versão deve ser ajustada para **remover o sufixo `-alpha`** (ex: de `1.6.0-alpha` para `1.6.0`), e deve ser realizada a publicação da versão final para produção.
18. Git Tags: Sempre que uma nova versão (seja a versão `-alpha` do Release Candidate ou a versão de produção final na `main`) for criada, gere uma tag git correspondente (ex: `git tag v1.6.0-alpha` ou `git tag v1.6.0`) e envie-a (push) com o comando `git push --tags`.

Constraints:
- Nunca atualize o Major automaticamente, mesmo se identificar "Breaking Changes".
- Garanta que a versão seja incrementada e configurada com o sufixo `-alpha` apenas na criação da branch de release candidate, e que builds finais na `main` tenham o sufixo `-alpha` removido.
- Siga sempre a ordem cronológica e lógica descrita acima quando sugerir ou atualizar a versão da aplicação nas conversas.