Versionamento da Kitanda

Sobre Kitanda:

A Kitanda é uma plataforma desenvolvida pela Quijaua, em consórcio com a Nômade Tecnologias, para atender à demanda do Instituto Terra Dourada com o projeto Mulheres Empreendedoras da Amazônia. Este projeto foi contemplado pela chamada pública Mover-se na Web, uma iniciativa do Nic.br. A plataforma tem como objetivo apoiar o desenvolvimento de empreendedores locais da Amazônia, promovendo a sustentabilidade e o crescimento de negócios na região.

Versionamento:
Uma forma eficiente e amplamente adotada no mercado para versionamento de software é o Semantic Versioning, também conhecido como SemVer. Essa metodologia ajuda a definir versões de maneira previsível e organizada.

O SemVer foi introduzido oficialmente com a versão 2.0.0 em 2013 por Tom Preston-Werner, cofundador do GitHub. Desde então, tornou-se um padrão amplamente utilizado por desenvolvedores e empresas para garantir compatibilidade entre versões e facilitar a manutenção de projetos.

Neste artigo, você entenderá melhor como o SemVer funciona e como ele está sendo utilizado na Kitanda.

O que é o SemVer?

O Semantic Versioning (SemVer) é um sistema de versionamento de software que segue o formato MAJOR.MINOR.PATCH, onde:

MAJOR

• Incrementado quando há mudanças incompatíveis com versões anteriores.

• Exemplo: Remover um método ou funcionalidade e substituí-los por outros com comportamento diferente.

MINOR

• Incrementado quando novas funcionalidades são adicionadas, mantendo a compatibilidade com versões anteriores.

• Exemplo: Introduzir uma nova ferramenta no software sem alterar a lógica das funcionalidades já existentes.

PATCH

• Incrementado para correções de bugs que não afetam a compatibilidade.

• Exemplo: Resolver um problema no software sem modificar ou adicionar novas funcionalidades.

Versões Alpha, Beta e Build no SemVer

Além das versões principais, menores e de correção, o SemVer também pode ser usado para definir versões alpha, beta e build. Essas versões são utilizadas para indicar estágios de desenvolvimento antes do lançamento oficial:

• Alpha: Versões iniciais de desenvolvimento, com funcionalidades experimentais. Geralmente instáveis. Exemplo: 1.0.0-alpha.1.

• Beta: Versões mais estáveis, mas ainda em testes, com algumas funcionalidades quase prontas. Exemplo: 1.0.0-beta.2.

• Build: Versões criadas a partir de commits específicos, geralmente usadas para testar mudanças contínuas. Exemplo: 1.0.0-20230315.

Essas versões ajudam a comunicar a maturidade do software e são importantes para que os usuários saibam em que estágio o software está e se ele pode ser utilizado de forma estável ou ainda contém experimentações.

Gerenciamento de atualizações de dependências

Na Kitanda é usado o SemVer para gerenciar as versões das dependências do projeto. No arquivo composer.json são usados os operadores de versão:

Entendendo os símbolos:

• ^4.17.1 → Permite atualizações automáticas de versões MINOR e PATCH dentro da mesma versão MAJOR (ex: 4.x.x), garantindo que nenhuma alteração que possa quebrar a compatibilidade seja introduzida.

• ~4.17.1 → Permite apenas atualizações de versão PATCH (ex: 4.17.x), o que assegura que pequenas correções e melhorias sejam aplicadas sem mudanças significativas no comportamento da dependência.

• 4.17.1 → Define a versão exata da dependência, sem permitir atualizações automáticas. Isso é útil quando se deseja garantir que sempre seja usada uma versão específica.

• >=4.17.1 → Permite qualquer versão maior ou igual à versão especificada, garantindo que a dependência não seja mais antiga, mas também não limita para uma versão mais recente.

• <5.0.0 → Limita a dependência a versões menores que 5.0.0, assegurando que qualquer atualização para versões MAJOR mais altas não será aplicada automaticamente.

Esses operadores ajudam a equilibrar flexibilidade e controle no gerenciamento das dependências, garantindo que o projeto da Kitanda continue evoluindo com estabilidade e sem surpresas indesejadas ao aplicar novas versões.

Criação de Releases e Tags

Na Kitanda, o SemVer é usado para definir as versões de releases e tags no Git/GitHub.

Releases são versões do código marcadas como estáveis, que podem incluir novos recursos, melhorias ou correções. Essas versões são associadas a tags no repositório, e as tags seguem o padrão SemVer.

Por exemplo, uma tag v1.2.0 indica que houve uma atualização MINOR (novos recursos, sem quebrar compatibilidade) e uma tag v1.2.1 pode indicar uma correção de PATCH (apenas correções de bugs).

Ao criar releases, a equipe pode garantir que os usuários estão sempre trabalhando com uma versão estável e bem definida do projeto, facilitando a comunicação sobre as mudanças feitas. As tags ajudam a identificar rapidamente versões específicas no histórico do Git.

Conclusão

O Semantic Versioning (SemVer) é uma prática fundamental para o gerenciamento eficaz de versões de software, proporcionando clareza e previsibilidade no desenvolvimento e manutenção de projetos.

A sua adoção na Kitanda permite um controle preciso sobre as dependências e as versões do código, assegurando a estabilidade e a compatibilidade entre as diversas versões do projeto. Ao usar o SemVer, a equipe pode facilmente comunicar mudanças significativas, novas funcionalidades e correções, além de manter um fluxo de trabalho organizado e eficiente, tanto no desenvolvimento quanto na publicação de releases.

O uso de tags e releases no Git/GitHub, aliado ao gerenciamento de dependências, facilita o acompanhamento da evolução do software, garantindo que as versões entregues sejam sempre bem definidas e seguras para os usuários. Dessa forma, o SemVer não só melhora a qualidade do software, mas também fortalece a colaboração e a confiança entre as equipes e os usuários finais.

Adotar uma abordagem de versionamento semântico é essencial para quem busca eficiência e estabilidade no desenvolvimento de software, seja em projetos pequenos ou grandes.