Ano passado, escrevi um artigo para o InfoQ sobre como o OSGi abandonou versões SNAPSHOT, e eu achei que levaria apenas um minuto para explicar o que eu quis dizer com o problema de “tooling humano”.

A questão é se SNAPSHOTs devem ou não ser construídos em um namespace numérico ‘inferior’ usando 1.2.3-456 que classifica menos do que 1.2.3. Ao incentivar diferenças entre versões “inéditas” e “liberadas”, torna-se claro se há mudanças importantes, e permite-se que os desenvolvedores reportem bugs em uma versão específica (em vez de apenas na versão mais recente).

De acordo com o Versionamento Semântico e as regras para Numeração de Versão do Eclipse, o número do patch (terceiro segmento) deve ser alterado sempre que há uma diferença entre a construção de artefatos. Como eu já havia listado no artigo do InfoQ, isso não acontece em alguns casos:

• org.eclipse.cdt.codan.checkers.ui_1.0.0.201109151620.jar
• org.eclipse.cdt.codan.checkers.ui_1.0.0.201202111925.jar
• org.eclipse.core.filebuffers_3.5.200.v20110505-0800.jar
• org.eclipse.core.filebuffers_3.5.200.v20110928-1504.jar
• org.eclipse.core.variables_3.2.500.v20110511.jar
• org.eclipse.core.variables_3.2.500.v20110928-1503.jar
• org.eclipse.emf.ecore_2.7.0.v20110912-0920.jar
• org.eclipse.emf.ecore_2.7.0.v20120127-1122.jar
• org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110506.jar
• org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110815-1438.jar
• org.eclipse.equinox.p2.updatesite_1.0.300.v20110510.jar
• org.eclipse.equinox.p2.updatesite_1.0.300.v20110815-1419.jar
• org.eclipse.jdt.compiler.tool_1.0.100.v_B76_R37x.jar
• org.eclipse.jdt.compiler.tool_1.0.100.v_B79_R37x.jar
• org.eclipse.jface_3.7.0.I20110522-1430.jar
• org.eclipse.jface_3.7.0.v20110928-1505.jar
• org.eclipse.ltk.core.refactoring_3.5.201.r371_v20110824-0800.jar
• org.eclipse.ltk.core.refactoring_3.5.201.r372_v20111101-0700.jar
• org.eclipse.pde.runtime_3.4.201.v20110819-0851.jar
• org.eclipse.pde.runtime_3.4.201.v20110928-1516.jar
• org.eclipse.ui_3.7.0.I20110602-0100.jar
• org.eclipse.ui_3.7.0.v20110928-1505.jar

O objetivo de mostrar o cross-section acima não é destacar projetos específicos, mas para mostrar que isso é um problema generalizado que acontece em todos os projetos. O problema é que não existe um “punição” por deixar um 1.2.3.qualifier como entrada do Manifest e apenas desencadeando compilações com novos qualifiers no local.

A vantagem de ter um formato diferente para numeração de versão entre versões de lançamento e versões de pré-lançamento é garantir que, no lançamento, o numero da versão é atualizado de forma adequada.  Isso significa que o processo de desenvolvimento geralmente segue:

• Crie 1.0.0-SNAPSHOT para desenvolvimento
• Trabalhe
• Versão 1.0.0
• Atualize para a versão 1.0.1-SNAPSHOT
• Trabalhe
• Lance 1.0.1 ou 1.1.0 (ou 2.0.0), conforme apropriado
• Vá para 10

A decisão sobre o que chamar o próximo número pode ser rastreada por atualizações SNAPSHOT em si (por exemplo, mudar para 1.1.0-SNAPSHOT) ou pode ser adiada para mais tarde no processo. Há ainda tooling para ajudá-lo a fazer isso (o plugin de lançamento mvn) – embora ele apenas remova os SNAPSHOTs para você, em vez de fazer qualquer análise semântica.

Esse padrão é tão comum que é até mesmo codificado como um ponto de bala na especificação de versionamento semântico:

Uma versão de pré-lançamento pode ser indicada, anexando um traço e uma série de pontos identificadores separados imediatamente após a versão patch. Identificadores devem ser compostos apenas de caracteres alfanuméricos ASCII e traço [0-9A-Za-z-]. Versões de pré-lançamento satisfazem, mas têm uma precedência mais baixa que a versão associada normal. Exemplos: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

“As versões de lançamento satisfazem, mas têm uma precedência mais baixa que” resume a regra: em outras palavras, em qualquer lugar que a 1.2.3 é válida, então tudo que é 1.2.3 é valido também, bem como em qualquer lugar que 1.2.3 não é válido, tudo que é 1.2.3 também não é valido. Assim, em uma série como [1.2.3,4.5.6], todo o estado de pré-lançamento de 1.2.3 está incluído, mas todo estado de pré-lançamento de 4.5.6, não esta incluído.

Isso foi até implementado com sucesso em Equinox, com uma implementação em 3.8M6.

Infelizmente, as preocupações listadas pelo CPEG estavam fora de sintonia com a forma como os desenvolvedores trabalham fora do espaço OSGi, e em vez de chegar com um mecanismo compatível com os artefatos lançados (proporcionando um estilo SNAPSHOT do sistema de construção que não seria carregável em antigas execuções OSGi), ele foi removido da especificação. Dado que OSGi R5 é um grande lançamento de execução, este teria sido o momento ideal para a introdução de uma nova versão de sintaxe, e que teria sido rapidamente adotada em outro lugar.

Então, em vez de ter nomes de artefatos “memoráveis” como org.eclipse.ui_3.7.0.jar, estamos presos com nomes não-memoráveis como org.eclipse.ui_3.7.0.v20110928-1505.jar para o futuro previsível no mundo OSGi. Isso faz com que haja mais trabalho cognitivo para os seres humanos (tentando lembrar o nome), enquanto a introdução de mais uma oportunidade para os erros (liberando o mesmo patch maior/menor com diferentes build).

Isso é o que eu chamo de seres humanos resolvendo o problema de tooling, em vez do contrário.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://alblue.bandlem.com/2012/03/human-tooling.html