Introdução

E aí pessoal, tenho ficado distante pacas, fazendo só posts dos links lidos na semana, mas hoje resolvi escrever alguma coisa, pouca e básica, mas não menos importante. Vou tentar fazer assim, para conseguir criar mais conteúdo e também me animar/agitar um pouco. Nesse exato momento estou ouvindo uma playlist chamada Melancholia, que tem músicas bem bacanas e que no momento está combinando um pouco comigo…

O que é versionar e por que versionar?

Antes mesmo de tudo, o que seria versionar um projeto? Todo projeto bem organizado possui um escopo, onde definimos certas metas a alcançar e para cada uma dessas metas, podemos criar uma espécie de release, que seria nossa versão.

Outro motivo para se versionar é que assim conseguimos “guardar” vários estágios daquele projeto e podemos continuar andando com o desenvolvimento. Assim as pessoas conseguem usar a versão que melhor lhes caber. É o que fazemos em geral com a maioria das bibliotecas e frameworks que utilizamos.

Usando o Semantic Version

Para manter um padrão mais organizado para versionar, nasceu um projeto chamado também de SemVer, que é um sistema bem básico. Ele é controlado pelo formato x.y.z:

Então, se tivéssemos, por exemplo, a versão 1.4.11, significaria que ela já teve sua primeira versão lançada, 4 novas features adicionadas depois e 11 correções.

Entendendo como versionar

Digamos que eu tenha uma simples API com um método all que retorna um array contendo todos os dados que eu desejo e essa é minha primeira versão estável da API, ela então terá a versão 1.0.0.

Depois de lançado, eu vi que dentro do meu método all, tinha um bug que fazia não retornar o último item do array. Eu apliquei a correção e lancei uma nova versão. Como era somente um bug, eu deverei mudar o valor da última casa e por isso a versão será 1.0.1.

Mais para frente eu resolvi criar um método chamado getItem(item), que é responsável por pegar um único item daquele array todo. Como eu adicionei uma nova feature, eu irei mudar o número do meio e resetar o último dígito, assim a versão ficará como 1.1.0, pois irei criar uma nova versão minor e essa ainda não teve nenhuma correção de bugs.

Se um dia eu resolver mudar as assinaturas dos métodos, modificando seus nomes e as formas de chamar, então será uma grande mudança e para isso eu irei alterar o primeiro número e por esta ser uma nova versão, os outros números serão resetados e com isso eu terei a versão 2.0.0.

Usando as tags do git para versionar

Eu aqui falei só na teoria como nomear e versionar, mas como fazer isso na real? Usando o git é muito simples, basta usarmos as tags.

O git permite dois tipos de tags que são annotated e non-annontated. A annotated tag permite guardar mais informações sobre aquela tag em si, como comentários e meta-informação.

Para criar uma tag basta:

Para listar todas as tags criadas, basta usar git tag. Se quiser apagar alguma tag use o comando git tag -d 1.0.0.

Lembre-se sempre de usar git push --tags para subir as tags criadas para o seu repositório remoto e também de usar git fetch --all para sincronizar as tags no seu local.

Caso você queira ver uma versão específica, use git checkout 1.0.0 e estará exatamente onde aquela versão parou, isso se torna extremamente útil.

Ferramentas para facilitar

Uns dias atrás, fazendo umas video-aulas muito legais sobre Como escrever uma biblioteca javascript opensource eu acabei encontrando uma ferramenta bem bacana para ajudar no versionamento, se chama semantic-release-cli, vale dar uma olhada tanto no curso quanto na ferramenta =)

Conclusão

Bom, a ideia desse post é fazê-los terem essa visão de que versionamento é importante e se ele for bem feito, só de ler os números de versões, já conseguimos entender se algo muito grande que mudou ou se algo foi adicionado ou corrigido. Passem a criar versões para suas libs e passem a fazê-las do modo certo, o mundo agradece.