Obtendo números de versão de software certas. v1.0.0.1 [fechado]

https://stackoverflow.com/questions/134517

02-07-2019
|

Pergunta

I distribuir software on-line, e sempre me pergunto se existe uma maneira correta de definir melhor os números de versão.

Vamos supor A.B.C.D nas respostas. Quando você aumentar cada um dos componentes?

Você usa quaisquer outros truques número da versão, como D mod 2 == 1 significa que é uma em liberação única casa?

Você tem versões beta com os seus próprios números de versão, ou você tem versões beta por número da versão?

Solução

Estou começando a gostar do Year.Release [.build] convenção de que alguns aplicativos (por exemplo Perforce) uso. Basicamente ele apenas diz o ano em que você soltar, ea sequência do mesmo ano. Então 2008.1 seria a primeira versão, e se você lançou outro um mês ou três depois, ele iria para 2008.2.

A vantagem deste sistema é que não há está implícito "magnitude" de lançamento, onde você entrar em discussões sobre se um recurso é grande o suficiente para justificar um grande incremento da versão ou não.

Um extra opcional é a tag sobre o número de compilação, mas que tende a ser apenas para fins internos (por exemplo adicionados ao EXE / DLL para que você possa inspecionar o arquivo e assegurar a compilação direita está lá).

Outras dicas

Na minha opinião, quase qualquer esquema de número liberação pode ser feita para um trabalho mais ou menos de forma saudável. O trabalho sistema I em números de versão usos tais como 11.50.UC3, onde o L indica 32 bits Unix, e o C3 é um número menor de revisão (fix pack); outras letras são usadas para outros tipos de plataformas. (Eu não recomendo este esquema, mas funciona.)

Existem algumas regras de ouro que até agora não foram declarados, mas que estão implícitos no que as pessoas têm discutido.

Não solte a mesma versão duas vezes -. Uma vez a versão 1.0.0 é liberado para ninguém, ele nunca pode ser re-lançado
números de versão deve aumentar monotonamente. Ou seja, o código na versão 1.0.1 ou 1.1.0 ou 2.0.0 deve ser sempre posterior à versão 1.0.0, 1.0.9 ou 1.4.3 (respectivamente).

Agora, na prática, as pessoas tem que liberar correções para versões mais antigas, enquanto as versões mais recentes estão disponíveis - ver GCC, por exemplo:

GCC 3.4.6 foi liberado após 4.0.0, 4.1.0 (e AFAICR 4.2.0), mas continua a funcionalidade do GCC 3.4.x em vez de adicionar os recursos extras adicionados ao GCC 4.x.

Então, você tem que construir o seu esquema de numeração versão cuidadosamente.

Um outro ponto que eu acredito firmemente em:

O número versão não está relacionado ao CM (VCS) versão do sistema de numeração, excepto para os programas triviais. Qualquer peça séria de software com mais de um arquivo de origem principal terá um número de versão sem relação com a versão de um único arquivo.

Com SVN, você poderia usar o número da versão SVN -. Mas provavelmente não como ela muda muito imprevisível

Para o trabalho de coisas que eu com o número da versão é uma decisão puramente política.

A propósito, eu sei de software que passou por lançamentos da versão 1.00 através de 9.53, mas que depois mudou para 2,80. Isso foi um erro grave - ditada pelo marketing. Concedido, versão 4.x do software é / era obsoleto, por isso não fazer imediatamente para a confusão, mas a versão 5.x do software ainda está em uso e vendidos, e as revisões já atingiram 3,50. Estou muito preocupado com o que o meu código que tem de trabalhar tanto com o 5.x (estilo antigo) e 5.x (novo estilo) vai fazer quando o inevitável conflito ocorre. Eu acho que tenho a esperança de que eles vão vadiar em mudar para 5.x até o velho 5.x realmente está morto - mas não estou otimista. Eu também uso um número de versão artificial, tal como 9,60, para representar o código de 3,50, para que eu possa fazer testes if VERSION > 900 sane, em vez de ter que fazer: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), onde eu represento versão 9.00 por 900. E depois há a mudança significativa introduzida na versão 3.00.xC3 - meu esquema não consegue detectar alterações no nível de release menor ... resmungar ... resmungar ...

NB : Eric Raymond fornece software Release Practice HOWTO incluindo a seção (ligada) em nomear lançamentos (numeração).

Eu costumo usar D como um contador de construção (incremento automático pelo compilador) I incrementar C cada vez que uma construção é liberado para "public" (não cada compilação é liberado) A e B são usados ??como número de versão principal / menor e alterado manualmente.

Eu acho que existem duas maneiras de responder a esta pergunta, e eles não são totalmente gratuito.

Técnico: versões Incremento baseados em tarefas técnicas. Exemplo: D é o número de compilação, C é a iteração, B é uma versão de menor, A é um grande lançamento. Definindo menores e maiores lançamentos é realmente subjetivo, mas pode estar relacionado coisas como alterações ao subjacente arquitetura.
Marketing: versões de incremento com base em quantos "novo" ou características "úteis" estão sendo prestados aos seus clientes. Você também pode amarrar os números de versão para uma política de atualização ... muda para uma exigem que o usuário a comprar uma licença de atualização, enquanto que outras mudanças não.

A linha de fundo, penso eu, é encontrar um modelo que funciona para você e seus clientes. Tenho visto alguns casos em que até mesmo as versões são lançamentos públicos, e versões ímpares são considerados beta, ou lançamentos dev. Eu vi alguns produtos que ignoram C e D todos juntos.

Depois, há o exemplo de Micrsoft, onde a única explicação racional para os números de versão para o .Net Framework é que o marketing estava envolvido.

A nossa política:

A - Significativa (> 25%) muda ou adições na funcionalidade ou interface.
B - pequenas mudanças ou adições na funcionalidade ou interface.
C - pequenas alterações que quebrar a interface.
D - correções para um construir que não altere o interface.

As pessoas tendem a querer fazer isso muito mais difícil do que realmente precisa ser. Se o seu produto tem apenas um único ramo de vida longa, apenas o nome versões sucessivas por seu número de compilação. Se você tem algum tipo de "pequenas correções de bugs são livres, mas você tem que pagar para grandes novas versões", então use 1.0, 1.1 ... 1.n, 2.0, 2.1 ... etc.

Se você não pode imediatamente descobrir o que o A, B, C e D no seu exemplo é, então obviamente você não precisa deles.

O único uso que eu já feitas do número de versão foi assim que um cliente poderia me dizer que eles estão usando a versão 2.5.1.0 ou o que quer.

A minha única regra é projetado para minimizar erros em relatórios que o número: todos os quatro números tem que ser 1 dígito única

1.1.2.3

é ok, mas

1.0.1.23

não é. Os clientes estão propensos a relatar ambos os números (verbalmente, pelo menos) como "um-um-dois-três".

Auto-incrementar números de compilação muitas vezes resulta em números de versão como

1.0.1.12537

que realmente não ajuda, tampouco.

Um bom e não técnica esquema apenas usa a data de construção neste formato:

YYYY.MM.DD.BuildNumber

Onde BuildNumber ou é um número contínuo (changelist) ou apenas recomeça em 1 a cada dia.

Exemplos: 2008.03.24.1 ou 2008.03.24.14503

Isto é principalmente para lançamentos internos, lançamentos públicos veria a versão impressa quanto 2008.03 se você não liberar mais frequentemente do que uma vez por mês. versões de manutenção ter sinalizado como 2008.03b 2008.03a e assim por diante. Eles raramente deve ir passado "c" mas se isso acontecer é um bom indicador de que você precisa melhor controle de qualidade e / ou procedimentos de teste.

campos Versão que são comumente vistos pelo usuário deve ser impressa em um formato amigável "March 2008", reservar a informação mais técnica na caixa de diálogo Sobre ou arquivos de log.

A maior desvantagem: apenas compilar o mesmo código no outro dia pode mudar o número da versão. Mas você pode evitar isso usando a lista de alterações de controle de versão como último número e verificar contra que para determinar se as necessidades de data para ser alterado também.

Eu uso V.R.M por exemplo 2.5.1

V (versão) mudanças são uma grande reformulação
R (revisão) mudanças são significativas novos recursos ou correções de bugs
H (modificação) alterações são correcções menores (Bux erros, etc)

Eu às vezes uso um SVN cometer número no final também.

É tudo muito subjetiva, no final do dia e simplesmente-se a si mesmo / a sua equipe.

Basta dar uma olhada em todas as respostas já -. Todos muito diferentes

Pessoalmente eu uso Major.Minor.*.* - Onde Visual Studio preenche o número Revison / build automaticamente. Isto é usado onde eu trabalho também.

Um bom user-friendly esquema de versionamento originou no antigo Mac OS é descrito nesta nota técnica Apple: http://developer.apple.com/technotes/tn/tn1132.html

eu como Year.Month.Day. Então, v2009.6.8 seria a "versão" deste post. É impossível duplicar (razoavelmente) e muito claro quando algo é uma versão mais recente. Você também pode deixar cair os decimais e torná-lo v20090608.

No caso de uma biblioteca, o número da versão informa sobre o nível de compatibilidade entre dois lançamentos, e, portanto, o quão difícil um upgrade será.

A necessidade de libertação correção de bug para preservar binário, fonte e compatibilidade de serialização.

Minor libera coisas significam diferentes para diferentes projetos, mas normalmente eles não precisam para preservar a compatibilidade fonte.

Principais números de versão pode quebrar todas as três formas.

Eu escrevi mais sobre a lógica aqui .

No mundo do github, tornou-se popular a seguir especificação de Tom Preston-Werner "semver" para números de versão.

A partir http://semver.org/ :

Dado um número de versão MAJOR.MINOR.PATCH, incrementar o:

versão principal quando você faz mudanças na API incompatíveis, versão secundária quando você adicionar a funcionalidade de uma forma compatível com versões anteriores, e PATCH versão quando você faz correções de bugs para trás compatíveis. Adicional etiquetas para metadados pré-lançamento e construção estão disponíveis como extensões para o formato MAJOR.MINOR.PATCH.

Para o desenvolvimento in-house, usamos o seguinte formato.

[Program #] . [Year] . [Month] . [Release # of this app within the month]

Por exemplo, se eu estou liberando aplicação # 15 hoje, e é a terceira atualização deste mês, em seguida, a minha versão # serão

15.2008.9.3

É totalmente fora do padrão, mas é útil para nós.

M.0.m.b

Nos últimos seis versões principais, nós usamos onde M é a versão principal, m é a versão menor, e b é o número de compilação. versões Então lançados incluídos 6.0.2, 7.0.1, ..., até 11.0.0. Não pergunte por que o segundo número é sempre 0; Pedi um número de vezes e ninguém realmente sabe. Nós não tivemos um diferente de zero lá desde 5.5 foi lançado em 1996.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow