Procurando melhores práticas para numeração de versões de componentes de software dependentes

Estamos tentando decidir sobre uma boa maneira de numerar as versões dos componentes de software, que dependem um do outro.

Vamos ser mais específicos:

O componente de software A é um firmware em execução em um dispositivo incorporado e o componente B é o respectivo driver para um PC normal (máquina Linux / Windows). Eles estão se comunicando usando um protocolo personalizado. Como nosso produto também é voltado para desenvolvedores, ofereceremos versões estáveis ​​e instáveis ​​(experimentais) de ambos os componentes (o firmware é de código fechado, enquanto o driver é de código aberto). Nossa maior dificuldade é como lidar com alterações de API no protocolo de comunicação.

Enquanto implementávamos uma verificação de compatibilidade no driver - ele verifica se a versão do firmware é compatível com a versão do driver - começamos a discutir várias maneiras de numerar as versões.

Chegamos a uma solução, mas também tínhamos vontade de reinventar a roda. É por isso que eu gostaria de receber algum feedback da comunidade de programadores / desenvolvedores de software, pois achamos que esse é um problema comum.

Então aqui está a nossa solução:

Planejamos seguir a numeração da versão major.minor.patch amplamente usada e usar números menores pares / ímpares para as versões estáveis ​​/ instáveis. Se introduzirmos alterações na API, aumentaremos o número menor.

Esta convenção levará à seguinte situação de exemplo:

O ramo estável atual é 1.2.1 e instável é 1.3.7. Agora, um novo patch para instável altera a API, o que fará com que o novo número da versão instável se torne 1.5.0. Uma vez que o ramo instável é considerado estável, digamos no 1.5.3, o lançaremos como 1.4.0.

Ficaria feliz em responder a qualquer uma das perguntas relacionadas abaixo:

• Você pode sugerir uma prática recomendada para lidar com os problemas descritos acima?
• Você acha que nossa convenção "personalizada" é boa?
• Que mudanças você aplicaria à convenção descrita?

Os números de versão do IMHO são como nomes de produtos; importante porque são visíveis, mas sem importância, pois são decoração e não conteúdo.

Ainda assim, o número da versão, como o nome do produto, possui significado. E a coisa mais importante que você pode fazer é evitar confusão. Então, aqui estão algumas expectativas comuns em relação aos números de versão. Na medida em que essas exceções não forem atendidas, o usuário provavelmente ficará confuso:

Os números de versão estão aumentando monotonicamente.
Essa é provavelmente a expectativa mais óbvia e, ao mesmo tempo, a menos provável de ser verdadeira. À primeira vista, o usuário espera que a versão 2.3.5 seja posterior à versão 2.2.17 e tenha a mesma ou melhor tecnologia. Mas é claro que o 2.3.x é um ramo de desenvolvimento e o 2.2.x é estável , e o 2.3.5 foi lançado em 2004 e o ramo 2.2 ainda está sendo trabalhado ativamente e o 2.2.17 foi lançado apenas em abril passado e contém. .. bem, você entendeu a idéia. Você também pode chamar a versão 2.2 "Batata" com todo o significado que o número carrega. Bem-vindo à versão " Potato-17 " !!

Versões semelhantes são atualizáveis ​​/ compatíveis
Se eu tenho a versão 3.7 no meu computador e o 3.8 sai com todos os novos frozbots brilhantes, espero que, com alguma atualização ou patch, o meu 3.7 possa se tornar 3.8 sem interrupção. Mas se eu estou no 3.7 e você libera o 5.2, não sou tão otimista. Claro, prefiro ser agradavelmente surpreendido do que decepcionado.

O primeiro dígito é significativo,
eu nem me daria ao trabalho de mencionar isso se Java não fosse tão proeminentemente confuso sobre o assunto. A menos que alguém lhe tenha dito, você não esperaria que o "Java 7" fosse realmente a versão 1.7. E a primeira vez que você ouviu isso, sua resposta foi quase certamente: " O quê? .. Por quê? "

Claramente, o purista dirá que o número da versão principal só será alterado se a alteração da plataforma não for compatível com versões anteriores. Mas você realmente pretende deixar para trás a compatibilidade nunca ? Freqüentemente, as principais revisões de versão são uma decisão de marketing e não técnica; o absurdo do Java vem dos dois campos ao mesmo tempo, com efeitos quase cômicos.

Finalmente,
como mencionei, os números de versão geralmente são tanto sobre marketing quanto sobre tecnologia. E tudo bem, já que é para isso que servem os números de versão: informe-o rapidamente sobre as novidades do software. Grande alteração de número significa grande alteração de funcionalidade. Pequena alteração no número significa quase nenhuma alteração na funcionalidade. Isso é o que as pessoas esperam . Se é verdade ou não, determina se os números de sua versão têm ou não o mesmo significado que seus usuários pensam que têm.

- EDIT -
Eu esqueci de mencionar isso, mas Caleb apontou bem: Não use números de versão para indicar algo importante (por exemplo, estável / instável) sem torná-lo explícito em outro lugar. Sim, você sabe que o número da versão menor ímpar indica desenvolvimento, mas isso faz de um de nós. O nome "instável" do Debian é um bom exemplo; ou você também pode usar um nome de produto totalmente separado; "Frozbot 1.2" para o nome do seu produto e "Devbot 1.3" para a sua versão de desenvolvimento.

Uma vez que o ramo instável é considerado estável, digamos no 1.5.3, o lançaremos como 1.4.0.

Não não. Para o 1.5.3 instável, o stable deve começar a partir do 1.6.0 (e o 1.4.x acabou de falhar, se você quiser usar o Semantic Versioning)

Você está tentando usar um valor para indicar duas coisas separadas.

Primeiro, você tem uma "versão", que geralmente serve para identificar os vários lançamentos e para indicar a ordem em que os lançamentos foram feitos. Como tylerl disse, a versão sempre deve aumentar - não fará sentido para os usuários (e também poderá causar muita confusão interna) se você alterar a versão de 1.5.3 para 1.4.0.

Segundo, você está tentando indicar se uma determinada versão é estável ou não.

É possível indicar as duas coisas com um único "número de versão", assim como algumas lojas usam algum esquema de preços para indicar se um item está à venda. Por exemplo, os preços que terminam em '3' em uma loja perto de mim são preços finais de venda. Isso funciona bem para os funcionários, que aprendem rapidamente como identificar um preço de venda, mas não é uma ótima maneira de informar seus clientes sobre uma venda. Por esse motivo, eles também colocam cartazes perto dos itens de venda. Você poderia fazer algo semelhante, como tornar o dígito menos significativo para versões estáveis ​​pares e tornar estranho para versões experimentais. Penso, porém, que, se você pretende lançar algo experimental, deve marcá-lo claramente dessa maneira. Você pode adicionar um 'X' no início ou no final da string da versão, como:X.1.5.31.5.3.X. Você pode até criar um número de versão experimental depois disso, para poder lançar várias versões experimentais, todas baseadas na mesma versão base: 1.5.3.X1, 1.5.3.X2.

Você também deve considerar que há uma longa tradição de usar "alfa" e números de versão "beta" para indicar versões que podem não ser estável ou completa: 1.5.3a54. Verifique se você tem um bom motivo para se afastar desse esquema se decidir fazer mais alguma coisa, porque provavelmente precisará explicar mais alguma coisa à sua comunidade de desenvolvedores.

Eu sugeriria usar o formato major.minor.patch, usando uma extensão "tag" para versões estáveis ​​/ instáveis ​​e um significado definitivo para os números maiores e menores:

major.minor.patch-stable|unstable

Onde

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

Dessa forma, as dependências são gerenciadas com facilidade e informarão cada cliente / usuário do componente quando precisar prestar mais atenção às novas versões. Por exemplo, se o componente A (1.1.0-estável) depende de B (5.4.534-estável) e uma nova versão do B estiver vencida (6.1.0-instável), é imediatamente ciente de que A terá que ser alterado, possivelmente substancialmente .

Eu realmente amo a maneira como o Hibernating Rhinos constrói o RavenDb em relação às versões - eles apenas têm um número de compilação cada vez maior. Quando eles ficam estáveis, eles ficam marcados como estáveis. Mas tudo é um candidato a lançamento.