Versionamento semântico de software.
Para entendermos o versionamento semântico, primeiro temos que entender o que é semântica. De acordo com o site portugues.com.br, a semântica é a área da linguística que estuda o significado e a sua relação com o significante. Essa palavra "significado" é super importante no contexto. Todo e qualquer software que seja desenvolvido por mais de um desenvolvedor deve estar amarrado à uma ferramenta de versionamento como git para facilitar as alterações, correções e criações necessárias. De cara, qualquer software possui um número de versão, seja ele 1.0, 2.4.4 ou 12.54.1298234. Se você ainda não entende muito de git, sugiro ler este artigo. Confirmo, no entanto, que o git sozinho não faz todo o necessário. Devemos ter um flow definido e organizado para nos ajudar na manutenção do projeto. Mais informações sobre git flow podem ser encontradas neste artigo.
Posso colocar qualquer número como versão da minha aplicação? Pode, mas não deve. Já vi casos em que a data é utilizada para a função, algo como 9.4.2022, mas mais a frente explico o porquê esta idéia não é muito interessante. O que geralmente utilizo são as regras presentes em https://semver.org/lang/pt-BR/, com 3 algarismos. O primeiro para alterações grandes/bruscas, como uma mudança completa nas telas da aplicação. O segundo para alterações grandes como adição de novas features e incompatibilidades como alterações de protocolos e assinaturas. O terceiro para alterações pequenas como correções de bug. Seguindo essa lógica o número presente no campo "version" do seu software passa a fazer sentido semanticamente.
Dependendo do tamanho da sua aplicação/projeto, ela será subdividida em pequenos (ou grandes) módulos responsáveis por pedaços da mesma. Esses módulos também precisam conter um número de versão, que por consequência não deve ser aleatório. Seguindo novamente o padrão sugerido no site mencionado acima, podemos colocar que, o primeiro número só deve ser alterado para mudanças grandes (algo como, refizemos ou reescrevemos a feature). O segundo deve ser alterado para adições de telas novas, adições de features e lógicas. O terceiro pode ser alterado para correções de bug pontuais ou alterações pontuais. A utilização do formato de data mostrado no exemplo acima força a amarração de features/código com uma data o que nem sempre fica muito claro. A pergunta: "O que subiu na versão do dia 02 de fevereiro de 2018?" na minha visão é mentalmente mais complexa do que a pergunta: "O que subiu na versão 1.2.3?", e fique tranquilo, vai acontecer.
Tudo isto deve ser levado em conta, principalmente no caso dos módulos porque queremos aqui evitar problemas de instalação dos mesmos na aplicação principal. Se temos um módulo como dependência de outros dois e atualizamos de forma errada o seu número de versão, podemos quebrar os dependentes e isso gera gargalos indesejados no desenvolvimento da aplicação. Se todos os desenvolvedores que trabalham em um mesmo projeto seguirem o mesmo padrão, a chance de acontecer algum problema de build na aplicação fica muito menor.
Lembre-se então: na hora de definir o número da versão do seu módulo/aplicação siga uma lógica a fim de evitar conflitos nas versões.
