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).
6. 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).
7. 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).
8. 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.
9. 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.