Pular para o conteúdo principal

Versionamento

· Leitura de 4 minutos

Para fazer o versionamento de código, utilizamos o GitHub, que como a maioria que conhece sabe, é a melhor ferramenta para este tipo de utilização.

Além do versionamento de código, temos o release e hotfix que são as formas de fazer o release de versão da aplicação de produção, e para isso seguimos o padrão de versionamento de SemVer.

O padrão SemVer é um dos padrões mais utilizados para versionamento de versões de sistemas. Com ele conseguimos controlar as versões de forma eficiente e sem problemas, especificando a que nível a modificação feita afeta o funcionamento do sistema.

O SemVer segue o seguinte padrão:

MAJOR.MINOR.PATCH - 1.0.0

Front End​

Major​

O incremento da versão MAJOR ocorre quando há mudanças que quebram a compatibilidade com a versão anterior. Esses são casos em que o sistema pode ter seu comportamento ou interface alterado de tal forma que usuários ou outros componentes que dependem dele precisam fazer ajustes para acompanhar a atualização. Exemplos de mudanças MAJOR incluem:

  • Novas funcionalidades que não sejam compatíveis com a versão anterior
  • Mudanças significativas no roteamento da aplicação que afetem fluxos de navegação dos usuários.
  • Alteração de dependências principais (como bibliotecas de UI) que possam impactar o funcionamento ou a aparência da aplicação.
  • Refatoração de funcionalidades que exijam ajustes em integrações ou chamadas de APIs que não são retrocompatíveis.

Minor​

A versão MINOR é incrementada quando novas funcionalidades são adicionadas de forma compatível com a versão anterior. São atualizações que melhoram ou ampliam a aplicação, mas que não exigem nenhuma modificação nas integrações existentes ou na forma como a interface é utilizada. Exemplos de mudanças MINOR incluem:

  • Adição de novos componentes ou serviços que não impactem a estrutura existente.
  • Expansão de funcionalidades em componentes já existentes, como novas opções de personalização ou configuração.
  • Inclusão de rotas ou telas adicionais, desde que não afetem a navegação padrão ou o comportamento dos componentes principais.
  • Ajustes visuais ou melhorias na interface que não alterem significativamente o comportamento.

Patch​

O incremento PATCH é reservado para correções de bugs e melhorias menores que não afetam a compatibilidade nem o comportamento do sistema. São alterações pontuais que garantem a estabilidade ou incrementam a qualidade visual e de usabilidade da aplicação, sem impacto para o usuário final ou para a integridade dos componentes. Exemplos de mudanças PATCH incluem:

  • Correção de bugs em componentes ou serviços.
  • Ajustes visuais (ex.: alinhamento, espaçamento) que não alteram a estrutura da interface.
  • Melhorias de desempenho ou otimização de carregamento de recursos.
  • Correção de comportamentos em animações ou em eventos de UI que não afetam a funcionalidade principal.

Nota: os commits que tenham BREAKING CHANGES devem de ter seu título iniciado com o char !, dessa maneira seguindo o padrão Conventional Commits, adotado também por este projeto.

Back End​

Major​

Aumentada quando houver BREAKING CHANGES, ou seja, mudanças incompatíveis com a versão anterior. Algumas dessas BREAKING CHANGES podem ser, mas não se limitam a:

  • Remoção de endpoints
  • Alteração de parâmetros de entrada obrigatórios em um endpoint
  • Alteração no sistema de autenticação
  • Novas funcionalidades que não sejam compatíveis com a versão anterior

Minor​

Aumentada quando forem inseridas ou removidas funcionalidades que não afetam a compatibilidade do sistema com sua versão anterior. Algumas dessas alterações podem incluir, mas não se limitam a:

  • Nova funcionalidade compatível com versão anterior
  • Novos endpoints (como eles ainda não estão sendo consumidos, não há quebra de compatibilidade)
  • Adição de parâmetros opcionais, tanto em GET, POST OU PUT.

Patch​

Aumentada em versões que corrigem bugs ou inserem melhorias que não impactam a interface pública (endpoints e suas comunicações)

Nota: os commits que tenham BREAKING CHANGES devem de ter seu título iniciado com o char !, dessa maneira seguindo o padrão Conventional Commits, adotado também por este projeto.