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.Documentation Index
Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
Use this file to discover all available pages before exploring further.
Versionamento semântico
Seguimos um esquema de versionamento semântico modificado no formato X.Y.Z [-designação], onde:
| Tipo de versão | Frequência de incremento | Características | Exemplo |
|---|---|---|---|
| X (Versão Major) | Avaliada a cada dois ciclos de desenvolvimento, mas só é lançada se houver mudanças significativas. | Pode introduzir breaking changes. Requer etapas explícitas de upgrade. | 1.0.0 → 2.0.0 |
| Y (Versão Minor) | A cada ciclo de desenvolvimento | Mantém compatibilidade retroativa. Introduz novas funcionalidades e recursos. | 1.0.0 → 1.1.0 |
| Z (Versão Patch) | Conforme necessário, fora do ciclo regular | Para hotfixes, patches de segurança e atualizações críticas. Mantém compatibilidade retroativa. | 1.1.0 → 1.1.1 |
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: Na v2, o campo
chartOfAccountsfoi removido e substituído portransactionRoute,routeFromerouteTopara mais clareza e controle. - Regras de validação: A variável de ambiente
ACCOUNT_TYPE_VALIDATIONfoi introduzida na v3, exigindo validação explícita de account type que antes era opcional. - Ciclo de depreciação: O campo
scaleemitiu avisos de depreciação na v2 antes de ser totalmente removido na v3.
Designações de pré-release
Usamos as seguintes designações de pré-release quando aplicável:
| Designação | Descrição | Características | Exemplo |
|---|---|---|---|
| -alpha.N | Builds iniciais de desenvolvimento. | Potencialmente instáveis, não destinados a produção. Podem conter funcionalidades incompletas. | 1.1.0-alpha.1 |
| -beta.N | Builds com funcionalidades completas em teste. | Adequados para ambientes de teste. Funcionalidades congeladas, foco em estabilidade e correções de bugs. | 1.1.0-beta.1 |
| -rc.N | Release Candidates. | Esperados como estáveis e prontos para produção. Apenas correções críticas antes do release final. | 1.1.0-rc.1 |
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