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.
(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.
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:
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:
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. 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 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. 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.
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.
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.
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.
Major.Minor.Public (compilação) [alpha / beta / trial], como "4.08c (1290)"
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
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!
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.
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 :
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. Major == 0 você está em alfa / pré-lançamento. Major > = 1 são seus lançamentos públicos.
1.5.3->1.5.4(bug fix) ->1.6.0(minor feature) ->2.0.0(breaking change)
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).
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 ).