Roadmaps, convenções para versões e Git Tagging

Você provavelmente já viu ou trabalhou em um softwares com versões, um exemplo disso é o navegador que está usando para ler este texto, este navegador provavelmente tem um número, este número é o que chamamos de número de versão ou simplismente versão, ele serve para discernir diferentes versões do mesmo software.

Neste texto vamos explorar como isto ocorre, conhecendo os termos Roadmap, as convenções de numeração para software e por fim como aplicar isto aos nossos repositórios git.

Roadmaps ou Milestones

Roadmap é um termo utilizado para indicar o mapa de desenvolvimento, de metas que se pretende alcançar e Milestone de um conjunto de metas que se deve cumprir para ir ao próximo nível, ambos são utilizados em diversas áreas, desde o desenvolvimento de produtos tangíveis até softwares.

Os roadmaps podem ser composto de diversos tipos de metas, como novos recursos, correções de bugs, melhorias de performance ou até de experiência do usuário.

Como falamos eles tem metas, estas métas são atreladas ao que chamamos de versões, como por exemplo, na versão 2.0 teremos o recurso X, Y e Z e a correção para os problemas X,P,T,O.

Eles também costumam ter datas estimadas de termino e em caso de trabalho em equipe as vezes podem ter pessoas responsáveis por executarem e verificarem aquelas tarefas.

Normalmente Roadmaps e Milestones são privados e internos de suas instituições, por motivos claros, como não apresentar a concorrência o que você está trabalhando ou não anunciar erros aos usuários que ainda não o tiveram, contudo projetos de código aberto normalmente custumam publicar seus planos, como por exemplo o WordPress no site http://wordpress.org/about/roadmap/, o Moodle no site

https://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel ou ainda o VLC no site https://trac.videolan.org/vlc/roadmap.

Uma forma de coletar e organizar suas metas, roadmaps ou milestones consiste na utilização de sistemas de bug tracking (como o Jira, Trac e Mantis ou ainda o Issue tracker do Github) e gerenciadores de projetos (como o Basecamp).

Embora bug tracking seja diretamente relacionado a catalogar e ajudar a exterminar bugs de programas é comum eles também serem utilizados para armazenar pedidos de recursos (features) ou melhorias em recursos já existentes.

Convenções de números de versão

Agora que você já tem seus bugs, requisições de novos recursos e melhorias você irá partir para montar o seu milestone, mas o milestone para que versão?

Uma convenção comum de ser visualizada é a MajorVersion.MinorVersion.PathVersion, vamos entender o que cada pedaço significa.

MajorVersion é o número dado para uma versão grande, normalmente uma versão que contem um grande número de recursos novos, ou uma mudança considerável no fluxo de trabalho, exemplos podem ser dados vendo softwares como Adobe Photoshop, veja abaixo a tabela com os números de versões e os recursos adicionados.

Versão	Descrição
1.0	Versão 1.0
2.0	Adicionado Paths, Suporte a cor CMYK e rasterização EPS
3.0	Adicionado Layer e paletas com abas.
4.0	Adicionado Actions e Layers de ajuste.
5.0	Adicionado a capacidade de editar textos, varios “Undo” (desfazer), gerenciamento de cores e o laço tool.
6.0	Adicionado Vector Shapes, Melhorada a interface do usuário, adicionado os estilos de layers.
7.0	O texto foi transformado em vetor, introdução do Healing Brush (o pincel de correção que os leigos acham super mágico)

Estas mudanças são tão grandes que podem ser consideradas um produto inteiramente novo, e em alguns casos chegam a ser vendidos como produtos diferentes e não apenas atualizações.

O segundo número chamado MinorVersion é referente a mudanças consideráveis, contudo não grandes o suficientes para dizer que é um novo software, usando o software Things como exemplo temos a seguinte tabela:

Versão	Descrição
1.0	Primeira versão
1.1	Adicionado suporte a applescript, nova forma de delegar todos, Adicionado suporte para sincronizar áreas com iOS app, Mudança de atalhos no teclado. etc.
1.2	Adicionado compatibilidade ao MacOSX, 10.6 Adicionado novos atalhos de teclado, Adicionado Autofill ao quick entry, Adicionado integração ao Sporlight etc.
1.3	Adicionado projetos misturados, Melhoria em localizações. Correção de bugs da versão 1.2.11

Já o último chamado PathVersion ou as vezes Revision Number é mais utilizado para correção de bugs e pequenas mudanças, ainda usando o Things como exemplo temos a seguinte tabela

Versão	Descrição
1.3	Adicionado projetos misturados, Melhoria em localizações. Correção de bugs da versão 1.2.11
1.3.1	Corrigido um erro relacionado a projetos misturados que acontecia usando a linguagem japonesa.
1.3.2	Agora dispositivos podem sincronizar simultaneamente pela rede local Painel de preferências do iPhone renomeado para devices.
1.3.3	Corrigido problema que resultava na versão 1.3.2 apresentar tela branca após abertura.
1.3.4	Things agora pergunta antes de apagar uma área não vazia, Adicionado um sistema para reportar crashs na app, Corrigido um problema onde o titulo de um projeto vazio iria impedir itens de aparecer na seção “Próximos”

Em alguns casos ainda podemos adicionar ainda letras as nossas versões, como nos exemplos abaixo.

Letra/Palavra	Exemplo	Significado
r	1.0r	r significa Release, ou seja produto final para distribuição
rc	1.0rc	rc significa Release Candidate, ele é um produto próximo da etapa de distribuição, mas ainda pode conter erros que podem ser arrumados antes da distribuição.
b	0.1b	b significa Beta, neste caso ele está em fase de testes, no qual procuramos erros de codigo que causem o programa a quebrar e erros de usabilidade ou de processos
a	0.1a	a significa Alpha, neste caso o software tem grandes chances de quebrar e jamais deve ser usado para produção ou aplicações críticas.

Normalmente após chegar na fase r você dispensa as letras e solta apenas com os números, um exemplo de uso do beta pode ser encontrado no blog da empresa Panic (produtora do coda) no anuncio dos betas de seus programas vide Link.

Dando um significado diferente entre pares e impares.

Algums projetos utilizam números impares para representarem versões instáveis de seus projetos e números pares para versões estáveis, isso pode ser visto dentro do MajorVersion ou do MinorVersion, um exemplo do MajorVersion pode ser encontrado no Nodejs.org, neste site no momento desta escrita há o histórico como o abaixo:

Versão	Estado
10.x	Estável
9.x	Instável
8.x	Estável
7.x	Instável
6.x	Estável
…	…

e no Kernel do Linux

Versão	Estado
2.6	Estável
2.5	Instavel
2.4	Estável

Contudo o próprio linux já deixou de usar esta prática.

Easter Egg

Em alguns casos empresas e programadores apelidam seus programas, no caso do WordPress são usados nomes de Compositores de Jazz, no MacOSX nomes de felinos, no caso do Android nome de doces e guloseimas, apelide os seus também é uma forma de você e seu time aumentarem seu comprometimento e diversão com a próxima versão de seu produto.

Git Tags (Tagging)

Estamos falando de versões e mudanças este artigo inteiro, chegamos agora na parte de versionamento, todo o projeto que se preze deve usar um sistema de versionamento seja ele Git ou Subversion, neste artigo vamos dar uma olhada no Git.

Tags no git são usadas para especificar pontos específicos na história como importante (segundo o site do git http://git-scm.com/book/en/Git-Basics-Tagging, para usar este recurso no git você pode usar os seguintes comandos:

Comandos Git Tag

Comando	Descrição	Exemplo
git tag	Lista as tags do repositório	git tag
git tag -a nome	Cria uma tag usando um nome	git tag -a v1.0
git tag -a nome -m mensagem	Cria uma tag usando um nome e uma mensagem	git tag -a v1.1.11 -m “Correção – Arrumado erro que impedia site de ser carregado”

GitHub

O github tem uma forma excelente de gerenciar repositórios, erros (recursos) e tags, como pode ser visto na aba Issues dos repositórios, caso você tenha uma empresa vale a pena contar com um bom repositório git, caso você possa pagar os 7$ mensais e tenha uma boa conexão com a internet você ganha também um ótimo bugtracker, gerenciador de milestones e wiki de forma privada.

Considerações

Espero que tenha elucidado alguns pontos sobre versões e versionamento, ajudando você a planejar suas milestones para a próxima versão de seu software e a escolher a designação mais adequada para a próxima release.