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

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 então 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.

Eu raramente me concordo completamente com Jeff Atwood, mas costumo seguir a opinião dele 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.

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.

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

Year.Month.Day.Build

Auto explicado.

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 muda para correções de bugs.

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

• N.x.K, onde Ne Ksão números inteiros. Exemplos: 1.x.0, 5.x.1, 10.x.33. Usado para construções intermediárias .
• N.M.K, Onde N, Me Ksão inteiros. Exemplos: 1.0.0, 5.3.1, 10.22.33. Usado para liberações .
• N.x.x, onde Né inteiro. Exemplo: 1.x.x. Usado para ramos de suporte .
• N.M.x, onde Ne Msão números inteiros. Exemplo: 1.0.x. Usado para ramificações de liberação .

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

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

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

• Representa detalhes do ciclo de vida do desenvolvimento ágil de software .
• Ele leva em consideração detalhes 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, que é básico para a abordagem de versão descrita, pode ser usado para reunir 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: build intermediário ( N.x.K) e release ( N.M.K). Release significa que um software com número de versão completo ( N.M.K) passou por algum tipo de processo de gerenciamento de qualidade na empresa / organização / equipe do fornecedor.
• É uma evidência de natureza ágil do desenvolvimento e do teste.
• Incentiva a abordagem modular à estrutura e arquitetura do software.

Há também um diagrama mais complexo que representa a abordagem de versionamento em detalhes. Além disso, você pode encontrar slides de apresentação úteis que descrevem a transição para a abordagem de versão e o aplicativo SCMFViz 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 da versão da data em vez dos números reais da versão 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 preocupe com a arquitetura ou a ideia de sua aplicação. O número da versão principal ( Nin N.M.K) é responsável pela solução arquitetural e pelo princípio subjacente do aplicativo. O número da versão principal Ndeve 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 sua base de código . Provavelmente existe apenas um ramo (tronco) e é usado para tudo. O que pessoalmente eu 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.

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 deu nomes como " Limp Lamprey ", " Wounded Wombat " e " Asthmatic Anteater ".

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

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 alterações 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.

git describefornece uma boa extensão 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ê nomeie suas versões de release marcadas como ABC (major.minor.maintenance). git describeem um determinado commit, encontrará o ancestral marcado mais recente do commit, depois inclua 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 bom benefício de informar exatamente de qual fonte você criou, sem precisar numerar todas as versões.

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 bugs.
• 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.

Prefiro números de versão que atribuem algum significado semântico. Desde que você possa usar o número da versão para rastrear os erros relatados com uma versão específica das alterações que ocorreram 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)
• revisão = revisão de subversão ou bazar (dependendo do projeto e qual o seu uso)

Sempre garantimos que o número da versão seja visível de alguma forma (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!

Usamos Major.Minor.Build # .YYMMDD [sufixo], como geralmente fazemos apenas uma produção em um determinado dia (mas usamos 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).

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.

Os números de versão devem ter informações suficientes para evitar conflitos e corrigir um erro nos problemas do tipo de versão incorreta, mas não devem transmitir informações adicionais que não são relevantes.

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

Eu pessoalmente gosto de versionamento semântico :

• Lançamentos são Major. Minor.Patch
• Patch incrementa toda vez que você libera uma compilação.
• Minor incrementa sempre que a funcionalidade compatível com versões anteriores é adicionada.
• Major incrementa 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.
• Os números mais baixos são redefinidos para 0 toda vez que você incrementa, então

  1.5.3-> 1.5.4(correção de bug) -> 1.6.0(recurso menor) -> 2.0.0(alteração de última hora)

              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 nosso número da versão interna. X.Yé o número da versão pública, aquela que tem um significado para nossos clientes. Quando uma X.Y.Zversão se torna pública, nunca haverá uma X.Y.(Z+1)versão: 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, crio uma nova Zversão quando penso que o aplicativo tem um conjunto de recursos 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, pretendo usar as Zversões numéricas para nomear um "alvo" de recursos, em nosso bugtracker.

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