Que “convenção de nomenclatura de versão” você usa? [fechadas]

102

As diferentes convenções de nomenclatura de versão são adequadas para diferentes projetos? O que você usa e por quê?

Pessoalmente, eu prefiro um número de compilação em hexadecimal (por exemplo, 11BCF), isso deve ser incrementado muito regularmente. E, em seguida, para os clientes, um simples número de versão de 3 dígitos, ou seja, 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.
    
por rjstelling 13.09.2010 / 12:43
fonte

13 respostas

44
Acho que raramente estou concordando completamente com Jeff Atwood, mas eu costumo seguir .html "> sua opinião sobre a convenção .NET de numeração de versões .

(Major version).(Minor version).(Revision number).(Build number)

Mais frequentemente do que não, para projetos pessoais, acho que isso é um exagero. As poucas vezes em que trabalhei em projetos substanciais, como mecanismos de pesquisa em C #, segurei essa convenção e consegui usá-la como um rastreador interno de maneira eficaz.

    
por 13.09.2010 / 15:06
fonte
87

O Versionamento Semântico ( link ) merece uma menção aqui. É uma especificação pública para um esquema de controle de versão, na forma de [Major].[Minor].[Patch] . A motivação para este esquema é comunicar o significado com o número da versão.

    
por 14.06.2011 / 15:35
fonte
33

Eu não uso, mas já vi e é uma estrutura interessante:

Year.Month.Day.Build

Auto-explicado.

    
por 13.09.2010 / 14:45
fonte
13

Eu tento usar a política do RubyGems Rational Versioning na qual:

  • O número da versão principal é incrementado quando a compatibilidade binária é quebrada
  • O número da versão secundária é incrementado quando uma nova funcionalidade é adicionada
  • O número da versão é alterado para correções de bugs.
por 11.11.2010 / 15:42
fonte
10

Aqui está uma abordagem muito refinada para a numeração de versões:

  • N.x.K , em que N e K são inteiros. Exemplos: 1.x.0 , 5.x.1 , 10.x.33 . Usado para construções intermediárias .
  • N.M.K , em que N , M e K são inteiros. Exemplos: 1.0.0 , 5.3.1 , 10.22.33 . Usado para lançamentos .
  • N.x.x , em que N é inteiro. Exemplo: 1.x.x . Usado para ramos de suporte .
  • N.M.x , em que N e M são inteiros. Exemplo: 1.0.x . Usado para ramos de lançamento .

Aqui está a foto para ilustração simples da abordagem de numeração de versão:

PA significa pré-alfa A significa alfa B significa beta AR significa liberação alfa BR significa versão beta RC significa candidato a lançamento ST significa estável

As vantagens dessa abordagem de numeração de versões são as seguintes:

  • Ele representa detalhes do ciclo de vida de desenvolvimento de software ágil .
  • Ele leva em conta detalhes específicos da estrutura do repositório do código-fonte .
  • É auto-explicativo para aqueles que se acostumaram com os padrões. Cada padrão representa um artefato diferente. Esses padrões podem ser facilmente analisados e usados para outros fins, como rastreamento de problemas.
  • Padrões de versão configurados, que são básicos para a abordagem de versão descrita podem ser usados para coletar métricas e planejamento .
  • É focado nos conceitos de maturidade e nível de qualidade . Frequentemente, números de versão como 1.0.0 são atribuídos sem muita necessidade (quando o software está em alpha profundo). A abordagem de numeração de versão apresentada permite estabelecer vários níveis de maturidade. No caso mais simples, ele terá apenas dois níveis: build intermediário ( N.x.K ) e release ( N.M.K ). Liberação significa que uma parte do software com o número completo da versão ( N.M.K ) passou por algum tipo de processo de gerenciamento de qualidade dentro da empresa / organização / equipe do fornecedor.
  • É uma evidência de natureza ágil de desenvolvimento e teste.
  • Incentiva abordagem modular à estrutura e arquitetura de software.

Há também um diagrama mais complexo que representa a abordagem de versão em detalhes. Além disso, você pode encontrar úteis slides de apresentação descrevendo a transição para a abordagem de controle de versão e SCMFViz que ilustra os princípios básicos da abordagem de numeração de versões. Os slides de apresentação também explicam por que é importante manter a mesma abordagem de versão durante toda a vida útil do projeto de software.

Pessoalmente, minha atitude em relação ao uso de versão de data em vez de números de versão real pressupõe que os desenvolvedores do software tenham versões datadas:

  • Não sabe nada sobre o ciclo de vida de desenvolvimento de software . O desenvolvimento é geralmente ágil e iterativo. A abordagem de numeração de versão deve representar a natureza iterativa do processo de desenvolvimento de software.
  • Não se preocupe com a qualidade do software . Controle de qualidade e garantia são ágeis e iterativos. Apenas como desenvolvimento. E o número da versão deve ser a evidência da natureza ágil e iterativa do desenvolvimento e do controle / garantia de qualidade.
  • Não se preocupe com a arquitetura ou com a ideia de sua aplicação. O número da versão principal ( N em N.M.K ) é responsável pela solução arquitetural e pelo princípio subjacente do aplicativo. O número da versão principal N deve ser alterado de acordo com as alterações na arquitetura ou alterações das principais ideias e princípios do seu funcionamento / funcionamento.
  • Não tem controle sobre a base de código . Há provavelmente apenas um ramo (tronco) e é usado para tudo. O que, pessoalmente, não acho correto, já que incentiva a base de código a se tornar um grande depósito de lixo.

Essa abordagem pode parecer um pouco controversa, mas acredito que essa seja a maneira mais direta de fornecer números de versão apropriados ao software.

    
por 19.01.2012 / 18:44
fonte
8

Para cada versão principal que você lançar, não é incomum ter uma versão funcional chamada internamente. Por exemplo, no meu último trabalho, nos referimos a uma versão principal com a seguinte convenção de nomenclatura inspirada no Ubuntu:

[condição doentia] [nome animal aliterativo]

Que deu nomes como " Limp Lamprey ", " Wound Wombat " e " Anteater asmático ".

Certifique-se de que, a menos que seja um nome realmente interessante, não vaze para seus clientes.

    
por 11.11.2010 / 16:54
fonte
6

Generation.Version.Revision.Build (9.99.999.9999)

A geração raramente muda. Apenas um grande turno no produto: DOS - > Windows, reengenharia completa.

A versão é para grandes alterações incompatíveis, novas funcionalidades, alterações em alguns paradigmas específicos no software, etc.

A revisão é feita frequentemente (recursos menores e correção de erros).

Compilação é informação interna.

    
por 13.09.2010 / 14:44
fonte
6

git describe oferece uma boa extensão para qualquer convenção de numeração escolhida. É bastante fácil incorporar isso em seu processo de criação / empacotamento / implantação.

Suponha que você nomeie suas versões de release marcadas como A.B.C (major.minor.maintenance). git describe em um determinado commit encontrará o ancestral com marcação mais recente do commit e, em seguida, terá o número de commits desde então, e o SHA1 abreviado do commit:

1.2.3-164-g6f10c

Se você está realmente em uma das versões, é claro, você só vai pegar a tag (1.2.3).

Isso tem o benefício de informar exatamente de qual fonte você criou, sem ter que numerar cada compilação.

    
por 11.11.2010 / 16:45
fonte
2

Major.Minor.Public (compilação) [alpha / beta / trial], como "4.08c (1290)"

  • Com Major sendo o número da versão principal (1, 2, 3 ...)
  • Menor sendo uma versão menor de 2 dígitos (01, 02, 03 ...). Normalmente, o dígito das dezenas é incrementado quando uma nova funcionalidade significativa é adicionada, apenas para as correções de bugs.
  • Público sendo o lançamento público da compilação (a, b, c, d, e), que geralmente é diferente da versão secundária, se uma versão secundária nunca for lançada como uma atualização pública
  • build, sendo o número de compilação real que o compilador controla.
  • com TRIAL, ALPHA, BETA X ou RC X anexados para esses casos especiais.
por 13.09.2010 / 21:19
fonte
2

Eu prefiro números de versão que atribuam algum significado semântico. Contanto que você possa usar o número da versão para rastrear bugs relatados com uma versão específica a alterações ocorridas no código-fonte (e no sistema de gerenciamento de atividades), provavelmente você está usando o método correto.

Eu uso o .NET, então estou preso ao sistema de numeração da versão .NET, mas tento dar significado semântico aos números, de modo que

major.minor.build.revision

  • major = (até o projeto)
  • menor = (até o projeto)
  • build = build número de Hudson (você poderia usar TeamCity ou TeamBuild, etc. aqui)
  • revision = subversão ou bazar revisão (dependendo do projeto e o que está usando)

Sempre nos certificamos de que o número da versão seja visível de alguma forma (com nossos programas baseados em console de lote impressos no console e um arquivo de log, com os aplicativos da web na barra de menus no topo)

Dessa forma, se os clientes relatarem problemas, poderemos usar o número da versão para rastrear se eles estão usando a versão mais recente e quantos problemas tivemos com versões específicas.

É tudo sobre rastreabilidade!

    
por 17.12.2010 / 21:34
fonte
1

Usamos Major.Minor.Build # .YYMMDD [suffix], já que normalmente fazemos apenas uma produção em um determinado dia (mas use o sufixo ab / c / d se houver mais de um ) e o YYMMDD fornece aos usuários / clientes / gerenciamento uma indicação da idade da construção, onde 6.3.1389 não.

Os números principais aumentam com recursos significativos do produto (pagos).

Números menores aumentam com correções / melhorias (atualização gratuita).

A compilação sempre aumenta; nem todos constroem navio, então não é uma progressão linear.

    
por 11.11.2010 / 16:18
fonte
1

Os números das versões devem ter informações suficientes para evitar conflitos e corrigir um bug nos problemas do tipo errado, mas não devem transmitir informações adicionais que não sejam relevantes.

Por exemplo, se você usar a data, os clientes poderão dizer que têm uma versão mais antiga e os patches contra versões antigas poderão ter versões confusas.

Eu pessoalmente gosto de versão semântica :

  • As versões são Major . Minor . Patch
  • Patch aumenta a cada vez que você libera uma versão.
  • Minor é incrementado sempre que uma funcionalidade compatível é adicionada.
  • Major aumenta quando a nova funcionalidade não é compatível com versões anteriores.
  • Quando Major == 0 você está em alfa / pré-lançamento. Major > = 1 são seus lançamentos públicos.
  • Números mais baixos são redefinidos para 0 sempre que você incrementa, então

    1.5.3 -> 1.5.4 (bug fix) -> 1.6.0 (minor feature) -> 2.0.0 (breaking change)

  •   
  Dessa forma, se alguém estiver usando, digamos, a versão 1.5.3 , poderá dizer rapidamente que poderia fazer o upgrade para 1.5.4 para obter as correções, que 1.6.0 adicionaria funcionalidade e que não deveria fazer upgrade para 2.0.0 (pelo menos sem lidar com a mudança).     
por 20.01.2012 / 11:56
fonte
0
              1.0.0
                |
              1.0.1
                |
(public 1.0)  1.0.2-----
                |       \
              2.0.0    1.1.0
                |        |
              2.0.1    1.1.1 (public 1.1)
                |
(public 2.0)  2.0.2-----
                |       \
              3.0.0    2.1.0
                         |
                       2.1.1 (public 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Z é o nosso número de versão interno. X.Y é o número da versão pública, aquele que tem um significado para os nossos clientes. Quando uma versão X.Y.Z se torna pública, nunca haverá uma versão X.Y.(Z+1) : a versão pública é sempre a última da série.

X é incrementado quando uma versão principal é lançada.

Y é usado para as ramificações de manutenção dessas principais versões, apenas para correções de bugs.

Z é usado internamente e não tem significado fixo. Até agora, criei uma nova versão Z quando penso que o aplicativo tem um conjunto de recursos que são interessantes para mostrar aos não desenvolvedores e é relativamente estável. Dessa forma, posso mostrar uma demonstração da "última versão válida" do aplicativo quando alguém perguntar a um. Em um futuro próximo, planejo usar as versões Z number para nomear um "alvo" de recursos, em nosso bugtracker.

Como nota lateral, usamos maven (com o comando release ) para incrementar o número da versão. Portanto, há X.Y.Z-SNAPSHOT versões também (o que indica qualquer versão entre X.Y.(Z-1) e X.Y.Z ).

    
por 12.11.2010 / 19:00
fonte