Qual versão esquema de numeração que você recomendaria?

StackOverflow https://stackoverflow.com/questions/121795

Pergunta

A minha pergunta é, qual esquema nomeando versão deve ser usada para o tipo de projeto.

Muito comum é major.minor.fix, mas mesmo isso pode levar a 4 série (ou seja Firefox 2.0.0.16). Alguns têm um modelo que números ímpares indicam programador de versões e até mesmo números de versões estáveis. E todos os tipos de adições pode entrar no mix, como -dev3, -rc1, SP2 etc.

Existe razões para preferir um sistema em detrimento de outro e devem diferente tipo de projectos (ou seja Open Source vs Closed Source) têm diferentes esquemas versão nomear?

Foi útil?

Solução

Existem dois boas respostas para isso (além de um monte de preferências pessoais, ver o comentário de aparelho em guerras religiosas)

Para públicas aplicações, o Major.Minor.Revision.Build padrão funciona melhor IMO - usuários públicos pode facilmente dizer qual a versão do programa que eles têm, e até certo ponto, até que ponto fora da data sua versão é.

Para em casa aplicações, onde os usuários nunca pediu a aplicação, a implantação é feita pela TI e os usuários será chamar o help desk, achei o Year.Month.Day.Build para trabalhar melhor em uma série de situações. Esse número de versão pode assim ser decodificado para fornecer informações mais úteis para o help desk, em seguida, o esquema de número pública de versão.

No entanto, no final do dia eu iria fazer uma recomendação acima de tudo - usar um sistema que você pode manter consistente . Se houver um sistema que você pode configurar / script seu compilador para usar automaticamente toda vez que, uso que .

A pior coisa que pode acontecer é você lançar binários com o mesmo número de versão como os anteriores - Eu recentemente lidado com relatórios de erro de rede automatizados (aplicação alguma outra pessoa), e chegou à conclusão de que a Year.Month números de versão .Day.Build mostrados na core dumps onde nem mesmo remotamente-se atualizado com o próprio aplicativo (o próprio aplicativo usado uma tela com os números reais - o que, naturalmente, onde não retirada do binário como se poderia supor). O resultado é que eu não tenho nenhuma maneira de saber se despejos de memória são provenientes de um binário de 2 anos (o que o número de versão indica) ou um dois meses binário antigo e, portanto, nenhuma maneira de obter o código fonte de direito (sem controle de origem, quer! )

Outras dicas

Aqui está o que nós usamos em nossa empresa:.... Principais menor versão patch número de compilação

O Principais mudança envolve um ciclo de lançamento completo, incluindo o envolvimento de marketing etc. Este número é controlado por forças fora do R & D (por exemplo, em um dos lugares que eu trabalhei, Marketing decidimos que a nossa próxima versão seria '11' -. Para coincidir com um concorrente Estávamos na versão 2 no momento :)).

menor é alterado quando um novo recurso ou uma grande mudança de comportamento é adicionado ao produto.

versão patch sobe por um cada vez que um patch é oficialmente adicionado à versão, geralmente incluindo correções de bugs somente.

Criar Versão é usado quando uma versão especial é liberado para um cliente, geralmente com uma correção de bug específico para ele. Normalmente, essa correção será lançado para o próximo patch ou versão secundária (e Gerenciamento de Produtos geralmente marca o bug como "será lançado para Patch 3" em nosso sistema de rastreamento).

Eu sou um grande fã de Semantic versionamento

Como muitos outros já comentou esta utiliza o formato x.y.z e dá boas razões por que motivo.

nosso departamento de R & D usa 1.0.0.0.0.000: MAJOR.minor.patch.audience.critical_situation.build

Por favor, por favor , não faça isso.

Este tipo de pergunta é mais sobre a guerra religião do que aspectos objetivos. Há sempre toneladas de prós e contras contra um esquema de numeração ou de outra. Todos os que as pessoas poderiam (ou deveriam) dar-lhe é o esquema que eles usaram e por que escolhê-lo.

Do meu lado, eu uso um esquema x.y.z tudo são números que:

  • X indicar uma mudança na API pública que introduzem incompatibilidade para trás
  • Y indicam uma adição de alguns recursos
  • Z indicar uma correcção (quer a fixação de um erro, quer mudar a estrutura interna sem impactar Funcionalidades de)

Por fim, eu uso o sufixo "Beta N" se eu quero algum feedback dos usuários antes de um lançamento oficial é feito. Sem sufixo "RC", como ninguém é perfeito e sempre haverá erros; -)

Eu pessoalmente prefiro MAJOR.MINOR.BUGFIX-SUFFIX onde sufixo é dev para as versões de desenvolvimento (checkouts de controle de versão), rc1 / rc2 para os candidatos de lançamento e não sufixo para versões de lançamento.

Se você tiver sufixos para checkouts de desenvolvimento, talvez até mesmo com o número de revisão, não há necessidade de torná-los ainda / estranho para mantê-los separados.

Nós preferimos esquema major.minor.milestone.revision-build, onde:

  • major:. Incrementos sobre mudanças arquitetônicas significativas ou avanços importantes nas capacidades
  • minor:. Pequenas mudanças e novas funcionalidades que não requerem mudanças na arquitetura
  • milestone: Indica estabilidade e maturidade do código:
    • 0 para o desenvolvimento / pre-alpha
    • 1 para alfa
    • 2 para beta
    • 3 para release candidate (RC)
    • 4 para versão final de produção /
  • revision:. Indica libertação, penso ou número de correções
  • build: referências únicas para específico constrói, ou versões, de um aplicativo. número de compilação é um número inteiro sequencial, normalmente incrementado a cada compilação.

Exemplos:

  • 1.4.2.0-798:. Primeiro lançamento beta da versão 1.4, criado pelo número de compilação 798
  • 1.8.3.4-970:. 1.8-RC4, criado pelo número de compilação 970
  • 1.9.4.0-986:. Primeiro lançamento da versão 1.9, criado pelo número de compilação 986
  • 1.9.4.2-990:. Liberação Segundo bugfix da versão 1.9, criado pelo número de compilação 990

Desde prodcution lançamentos têm sempre 4 em seu terceiro dígito da cadeia de versão, o dígito pode ser removido para versões de produção.

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 .

Com práticas e SaaS desenvolvimento ágil de software aplicativos, a idéia de uma versão principal vs. um Menor desapareceu - lançamentos saem extremamente frequentemente em uma base regular - então um esquema de numeração versão que conta com esta distinção não é mais útil para mim.

Minha empresa usa um esquema de numeração que leva os últimos 2 dígitos do ano o lançamento começou seguido pelo número da versão do mesmo ano.

Assim, a 4ª liberação começou em 2012 seria 12,4.

Você pode incluir um número de versão "bug fix" depois disso, se necessário, mas o ideal é que você está lançando com frequência suficiente para que estes não são muitas vezes necessário -. Modo "12.4.2"

Este é um esquema muito simples e não nos deu qualquer dos problemas de outros esquemas de numeração de liberação que eu usei antes.

A diferença entre uma política número próximo e open-source versão também pode vir de um aspecto comercial , quando a versão principal pode refletir o ano do lançamento, por exemplo.

O que nós costumávamos fazer aqui é major.minor.platform.fix .

importante :. Nós aumentar esse número quando salvo arquivo desta compilação não são compatíveis com a compilação anterior
Exemple :. Arquivos salvos na versão 3.0.0.0 não será compatível com a versão 2.5.0.0

menor : Nós aumentar esse número quando um novo recurso foi adicionado. Este recurso deve ser visto pelo usuário. Não é um recurso escondido por developper. Este número é reposto a 0 quando grande é incrementado.

plataforma : Esta é a plataforma que usamos para developpement
. Exemple :. 1 significa NET Framework versão 3.5

correção : Nós aumentar esse número quando apenas correções de bugs estão incluídos com esta nova versão. Este número é reposto a 0 quando maior ou menor é incrementado.

Simplesmente 

Major.Minor.Revision.Build
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top