Versionamento semântico
Seguimos um esquema de versionamento semântico modificado no formato X.Y.Z [-designação], onde:
Breaking changes
Um breaking change ocorre quando uma atualização altera ou remove um comportamento de um jeito que não é totalmente compatível com versões anteriores. Para manter esse processo previsível, seguimos regras rígidas e comunicamos com antecedência.
- Introduzimos breaking changes apenas em uma versão principal.
- Eles são anunciados com antecedência, sempre com guias de migração e exemplos.
- Funcionalidades descontinuadas emitem avisos antes da remoção, para que as equipes tenham tempo de se adaptar.
- Buscamos minimizar as interrupções agrupando breaking changes e oferecendo soluções alternativas sempre que possível.
Exemplos
- Substituição de campo: o
routeId(UUID) substituiu o campo de texto livreroutenos payloads de transação. O camporoutecontinua aceito para compatibilidade retroativa, mas não controla mais a validação. - Regras de validação: a API Ledger Settings substituiu as variáveis de ambiente
ACCOUNT_TYPE_VALIDATIONeTRANSACTION_ROUTE_VALIDATION. A API controla a validação contábil por ledger sem novo deploy. - Ciclo de descontinuação: removemos o campo
scaledos valores de transação na v3, quando o tratamento de valores passou para um sistema numérico.
Designações de pré-release
Usamos as seguintes designações de pré-release quando aplicável:
Exemplos
Possíveis releases- 1.0.0 → Release estável inicial
- 1.0.1 → Patch com correções de bugs
- 1.1.0-alpha.1 → Alpha para a próxima versão secundária
- 1.1.0-beta.1 → Beta para a próxima versão secundária
- 1.1.0-rc.1 → Release candidate
- 1.1.0 → Release secundário estável
- 1.2.0 → Próximo release secundário
- 2.0.0 → Nova versão principal

