Skip to main content
O esquema de versionamento descreve como atribuímos e incrementamos os números de versão. Ele esclarece o significado de releases major, minor e patch, como lidamos com breaking changes e o papel das tags de pré-release. Seguindo esta estrutura, você pode antecipar o impacto de cada atualização e planejar migrações com confiança.

​
Versionamento semântico

Seguimos um esquema de versionamento semântico modificado no formato X.Y.Z [-designação], onde:

​
Breaking changes

Breaking changes fazem parte da evolução natural da plataforma. Acontecem quando uma atualização altera ou remove um comportamento de forma incompatível com versões anteriores. Para manter esse processo previsível, seguimos regras estritas e comunicamos com antecedência, permitindo que seus times se preparem com confiança.
  • Breaking changes são introduzidas apenas em uma versão major.
  • São anunciadas com antecedência, sempre com guias de migração claros e exemplos práticos.
  • Funcionalidades depreciadas emitem avisos antes da remoção, dando aos times tempo para se ajustar sem impacto repentino.
  • Buscamos minimizar a disrupção agrupando breaking changes e fornecendo soluções alternativas sempre que possível.

​
Exemplos

  • Substituição de campo: O campo de texto livre route nos payloads de transação foi substituído pelo routeId (UUID); route continua aceito por compatibilidade, mas não participa mais da validação.
  • Regras de validação: As variáveis de ambiente ACCOUNT_TYPE_VALIDATION e TRANSACTION_ROUTE_VALIDATION foram substituídas pela API de Configurações do Ledger, que controla a validação contábil por ledger sem necessidade de novo deploy.
  • Ciclo de depreciação: O campo scale foi removido dos valores de transação na v3, quando o tratamento de valores passou a um sistema numérico.

​
Designações de pré-release

Usamos as seguintes designações de pré-release quando aplicável:

​
Exemplos

Releases possíveis
  • 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 minor
  • 1.1.0-beta.1 → Beta para a próxima minor
  • 1.1.0-rc.1 → Release candidate
  • 1.1.0 → Release minor estável
  • 1.2.0 → Próximo release minor
  • 2.0.0 → Nova versão major