ti-enxame.com

Que "convenção de nomenclatura de versão" você usa?

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

Pessoalmente, prefiro um número de compilação em hexadecimal (por exemplo, 11BCF), que deve ser incrementado com muita regularidade. E, para os clientes, um número de versão simples 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.
111
rjstelling

Eu raramente me concordo completamente com Jeff Atwood, mas costumo seguir sua opinião sobre a convenção .NET de numeração de versões .

(versão principal). (Versão secundária). (Número da revisão). (Número da versão)

Na maioria dos casos, para projetos pessoais, acho que isso é um exagero. Nas poucas vezes em que trabalhei em projetos substanciais, como mecanismos de pesquisa em C #, aderi a esta convenção e pude usá-la como um rastreador interno de forma eficaz.

47
Mike B

Versão semântica ( http://semver.org/ ) merece uma menção aqui. É uma especificação pública para um esquema de versão, na forma de [Major].[Minor].[Patch]. A motivação para esse esquema é comunicar significado com o número da versão.

90
M. Dudley

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

Year.Month.Day.Build

Auto explicado.

33
Maniero

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 é interrompida
  • O número da versão secundária é incrementado quando nova funcionalidade é adicionada
  • O número da compilação é alterado para correções de bugs.
14
Ken Bloom

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

  • N.x.K, onde N e K são números inteiros. Exemplos: 1.x.0, 5.x.1, 10.x.33. Usado para compilações intermediárias.
  • N.M.K, onde N, M e K são números inteiros. Exemplos: 1.0.0, 5.3.1, 10.22.33. Usado para releases.
  • N.x.x, onde N é um número inteiro. Exemplo: 1.x.x. Usado para ramificações de suporte.
  • N.M.x, onde N e M são números inteiros. Exemplo: 1.0.x. Usado para liberar ramificações.

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

Agile version numbering

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

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

  • Ele representa detalhes de ciclo de vida do desenvolvimento de software ágil.
  • Ele leva em consideração as especificações da estrutura do repositório de código fonte.
  • É auto-explicativo para aqueles que se acostumaram com os padrões. Todo padrão representa artefato diferente. Esses padrões podem ser facilmente analisados ​​e usados ​​para outros fins, como rastreamento de problemas.
  • Conjunto de padrões de versão, básico para a abordagem de versão descrita, que pode ser usado para coletar métricas e planejamento.
  • É focado nos conceitos de maturidade e nível de qualidade. Muitas vezes, números de versão como 1.0.0 são atribuídos sem muita necessidade (quando o software está em alfa 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: construção intermediária (N.x.K) e release (N.M.K). Versão significa aquele software com o número da versão completa (N.M.K) passou por algum tipo de processo de gestão da 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 do software.

Também há mais complexo diagrama representando a abordagem de versão em detalhes. Além disso, você pode achar útil slides da apresentação descrevendo a transição para a abordagem de versão e SCMFViz aplicativo ilustrando os princípios básicos da abordagem de numeração de versão. Os slides da 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 da data em vez de números de versão reais pressupõe que os desenvolvedores do software com 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 . O controle e a garantia da qualidade são ágeis e iterativos. Assim como o desenvolvimento. E o número da versão deve ser a evidência de natureza ágil e iterativa do desenvolvimento e do controle/garantia de qualidade.
  • Não se preocupam com arquitetura ou ideia de sua aplicaçã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 mudanças na arquitetura ou nas principais idéias e princípios de seu funcionamento/funcionamento.
  • Não tem controle sobre a base de código . Provavelmente existe apenas um ramo (tronco) e é usado para tudo. O que pessoalmente não acho certo, pois 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 seja a maneira mais direta de fornecer números de versão apropriados ao software.

10
altern

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

[doença doentia] [nome aliterativo do animal]

Que deram nomes como "Lampreia Limp", "Wombat ferido" e "Tamanduá asmático".

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

8
Jesse C. Slicer

Generation.Version.Revision.Build (9.99.999.9999)

Geração raramente muda. Apenas uma grande virada no produto: DOS -> Windows, reengenharia completa.

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

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

Build é uma informação interna.

7
Maniero

git describe fornece uma extensão agradável para qualquer convenção de numeração que você escolher. É fácil incorporar isso no seu processo de compilação/empacotamento/implantação.

Suponha que você atribua um nome às versões de liberação com etiqueta A.B.C (major.minor.maintenance). git describe em um determinado commit, encontrará o ancestral marcado mais recente do commit, depois incluirá o número de commits desde então e o SHA1 abreviado do commit:

1.2.3-164-g6f10c

Se você está de fato em uma das versões, é claro, receberá a tag (1.2.3).

Isso tem o benefício agradável de informar você exatamente de qual fonte você criou, sem precisar numerar todas as versões.

6
Cascabel

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

Como uso o .NET, estou preso ao sistema de numeração de versões do .NET, mas tento atribuir significado semântico aos números.

major.minor.build.revision

  • major = (até o projeto)
  • menor = (até o projeto)
  • build = número da build do Hudson (você pode usar o TeamCity ou TeamBuild, etc. aqui)
  • revision = revisão do Subversion ou Bazaar (dependendo do projeto e qual o seu uso)

Sempre garantimos que o número da versão seja visível de alguma maneira (com nossos programas baseados em console em lote impressos no console e em um arquivo de log, com os aplicativos da Web na barra de menus na parte superior)

Dessa forma, se os clientes reportarem problemas, podemos 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!

2
Jeffrey Cameron

Major.Minor.Public (build) [alfa/beta/trial], como "4.08c (1290)"

  • Sendo Major o número da versão principal (1, 2, 3 ...)
  • Menor sendo uma versão secundária de 2 dígitos (01, 02, 03 ...). Normalmente, o dígito das dezenas é incrementado quando novas funcionalidades significativas são adicionadas, apenas para correção de erros.
  • Público é 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
  • sendo o número de compilação real que o compilador mantém o controle.
  • com TRIAL, ALPHA, BETA X ou RC X anexados a esses casos especiais.
2
GrandmasterB

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

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

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

A construção sempre aumenta; nem todas as embarcações são construídas, portanto não é uma progressão linear.

1
JBRWilkinson
 1.0.0 
 | 
 1.0.1 
 | 
 (Público 1.0) 1.0.2 ----- 
 |\
 2.0.0 1.1.0 
 | | 
 2.0.1 1.1.1 (público 1.1) 
 | 
 (Público 2.0) 2.0.2 ----- 
 |\
 3.0.0 2.1.0 
 | 
 2.1.1 (público 2.1) 
 | 
 2.2.0 
 | 
 2.2.1 

X.Y.Z É o número da nossa versão interna. X.Y É o número da versão pública, aquela que tem um significado para 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 versões principais, apenas para correções de bugs.

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

Como observação, usamos o maven (com o comando release) para aumentar o número da versão. Portanto, também existem versões X.Y.Z-SNAPSHOT (Que indica qualquer versão entre X.Y.(Z-1) e X.Y.Z).

0
barjak