O que os números em uma versão normalmente representam (por exemplo, v1.9.0.1)?

Talvez essa seja uma pergunta boba, mas sempre presumi que cada número delineado por um período representasse um único componente do software. Se isso é verdade, eles representam algo diferente? Gostaria de começar a atribuir versões às diferentes versões do meu software, mas não tenho muita certeza de como deve ser estruturado. Meu software possui cinco componentes distintos.

Na versão 1.9.0.1 :

• 1 : Revisão principal (nova interface do usuário, muitos novos recursos, mudança conceitual etc.)

• 9 : Revisão secundária (talvez uma alteração em uma caixa de pesquisa, 1 recurso adicionado, coleção de correções de bugs)

• 0 : Lançamento de correção de bug

• 1 : Número da compilação (se usado) - é por isso que você vê a estrutura .NET usando algo como 2.0.4.2709

Você não encontrará muitos aplicativos que vão para quatro níveis, 3 geralmente é suficiente.

Existe a especificação de versionamento semântico

Este é o resumo da versão 2.0.0:

Dado um número de versão MAJOR.MINOR.PATCH, aumente o:

1. Versão MAJOR quando você faz alterações incompatíveis da API,
2. Versão menor quando você adiciona funcionalidade de uma maneira compatível com versões anteriores e
3. PATCH versão quando você faz correções de bugs compatíveis com versões anteriores.

Rótulos adicionais para pré-lançamento e compilação de metadados estão disponíveis como extensões para o formato MAJOR.MINOR.PATCH.

Pode ser muito arbitrário e difere de produto para produto. Por exemplo, com a distribuição Ubuntu, 8.04 refere-se a 2008.

Normalmente, os números mais principais (à esquerda) indicam uma versão principal e, quanto mais você vai para a direita, menor a alteração envolvida.

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

Quanto mais pontos, menor o lançamento. Não existe um padrão realmente sólido além disso - pode significar coisas diferentes com base no que os mantenedores do projeto decidem.

O WordPress, por exemplo, segue estas linhas:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 a 2.0 seria uma grande versão - recursos, alterações na interface, grandes mudanças nas APIs, quebra de alguns modelos e plugins 1.6 etc. 2.0 a 2.0.1 seria uma versão menor - talvez corrigindo um erro de segurança. 2.0.2 a 2.1 seria uma versão significativa - novos recursos, geralmente.

Os números podem ser úteis, conforme descrito por outras respostas, mas considere como eles também podem não ter sentido ... Sun, você sabe SUN, java: 1.2, 1.3, 1.4 1.5 ou 5 e depois 6. Nos bons e velhos números da versão do Apple II Alguma coisa. Atualmente, as pessoas estão desistindo dos números das versões e adotando nomes tolos como "Feisty fig" (ou algo parecido) e "hardy heron" e "europa" e "ganymede". É claro que isso é muito menos útil, porque você ficará sem luas de Júpiter antes de parar de mudar o programa, e como não há uma ordem óbvia, você não pode dizer qual é a mais nova.

Na versão v1.9.0.1: este é o esquema de versão explícito usado quando você não deseja usar o nome para as pré-liberações ou criar como -alpha, -beta.

1: versão principal que pode quebrar a compatibilidade com versões anteriores

9: Adição de novos recursos para oferecer suporte ao seu aplicativo, além de compatibilidade com versões anteriores da versão anterior.

0: Algumas pequenas correções

1: Número da versão (número de pré-lançamento)

mas hoje em dia você não encontra esse esquema de versão. Consulte Semantic Versioning [semver2.0] https://semver.org/

Os números de versão geralmente não representam componentes separados. Para algumas pessoas / software, os números são bastante arbitrários. Para outros, partes diferentes da sequência do número da versão representam coisas diferentes. Por exemplo, alguns sistemas aumentam partes do número da versão quando um formato de arquivo é alterado. Portanto, o V 1.2.1 é um formato de arquivo compatível com todas as outras versões do V 1.2 (1.2.2, 1.2.3 etc.), mas não com o V 1.3. Em última análise, cabe a você qual esquema você deseja usar.

Geralmente é:

MajorVersion.MinorVersion.Revision.Build

Depende, mas a representação típica é a de major.minor.release.build .

Onde:

• major é a versão principal do seu software, pense no .NET 3.x
• minor é a versão menor do seu software, pense no .NET x.5
• release é o lançamento dessa versão, normalmente as correções de bugs incrementam esse
• build é um número que indica o número de builds que você executou.

Por exemplo, 1.9.0.1, significa que é a versão 1.9 do seu software, seguindo 1.8 e 1.7, etc. onde 1.7, 1.8 e 1.9, de alguma forma, geralmente adicionam pequenas quantidades de novos recursos juntamente com as correções. Como é xx0.x, é a versão inicial do 1.9 e é a primeira compilação dessa versão.

Você também pode encontrar boas informações no artigo da Wikipedia sobre o assunto .

Major.Minor.Bugs

(Ou alguma variação nisso)

Bugs geralmente são correções de erros sem novas funcionalidades.

Pequenas são algumas mudanças que adicionam novas funcionalidades, mas não alteram o programa de maneira importante.

Principal é uma alteração no programa que quebra a funcionalidade antiga ou é tão grande que, de alguma forma, altera a maneira como os usuários devem usar o programa.

Todo mundo escolhe o que quer fazer com esses números. Fui tentado a chamar releases de abc, já que é bastante bobo. Dito isto, o que vi nos últimos 25 anos de desenvolvimento tende a funcionar dessa maneira. Digamos que o número da sua versão seja 1.2.3.

O "1" indica uma revisão "principal". Geralmente, este é um release inicial, uma grande alteração no conjunto de recursos ou uma reescrita de partes significativas do código. Depois que o conjunto de recursos é determinado e pelo menos parcialmente implementado, você passa para o próximo número.

O "2" indica um lançamento dentro de uma série. Freqüentemente usamos essa posição para nos atualizarmos com os recursos que não chegaram à última versão principal. Esta posição (2) quase sempre indica uma adição de recurso, geralmente com correções de erros.

O "3" na maioria das lojas indica uma liberação de patch / correção de bug. Quase nunca, pelo menos no lado comercial, isso indica um recurso significativo. Se os recursos aparecerem na posição 3, provavelmente é porque alguém fez o check-in antes que soubéssemos que tínhamos que fazer uma correção de bug.

Além da posição "3"? Eu não tenho idéia de por que as pessoas fazem esse tipo de coisa, fica mais confuso.

Notavelmente alguns dos OSS por aí jogam tudo isso fora de moda. Por exemplo, a versão 10 do Trac é realmente 0.10.XX Eu acho que muitas pessoas no mundo OSS não têm confiança ou simplesmente não querem anunciar que eles têm um grande lançamento.

No arquivo C # AssemblyInfo.cs, você pode ver o seguinte:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revision seria o meu palpite.
Mas isso pode variar bastante entre os produtos.

Major.minor.point.build normalmente. Maior e menor são auto-explicativos, point é uma versão para algumas pequenas correções de bugs e build é apenas um identificador de build.

Sim. As principais versões adicionam novos recursos grandes, podem quebrar a compatibilidade ou ter dependências significativamente diferentes etc.

Versões menores também adicionam recursos, mas são versões portadas menores, às vezes reduzidas, da versão beta principal.

Se houver um terceiro componente de número de versão, geralmente é para importantes correções de bugs e correções de segurança. Se houver mais, realmente depende tanto do produto que é difícil dar uma resposta geral.

O paradigma da correção principal release.minor release.bug é bastante comum, eu acho.

Em alguns contratos de suporte empresarial, há $$$ (ou quebra de responsabilidade do contrato) associada à forma como uma liberação específica é designada. Um contrato, por exemplo, pode dar ao cliente um certo número de releases principais em um período de tempo, ou prometer que haverá menos de x número de releases secundários em um período ou que o suporte continuará disponível para muitos lançamentos. Obviamente, não importa quantas palavras sejam colocadas no contrato para explicar o que é uma versão principal versus uma versão menor, ela é sempre subjetiva e sempre haverá áreas cinzentas - levando à possibilidade de o fornecedor do software fazer o sistema funcionar. superar tais disposições contratuais.

As pessoas nem sempre reconhecem a diferença sutil entre números de versão como 2.1, 2.0.1 ou 2.10 - pergunte a uma pessoa do suporte técnico quantas vezes eles tiveram problemas com isso. Os desenvolvedores são orientados a detalhes e familiarizados com estruturas hierárquicas, portanto esse é um ponto cego para nós.

Se possível, exponha um número de versão mais simples aos seus clientes.

No caso de uma biblioteca, o número da versão informa sobre o nível de compatibilidade entre duas versões e, portanto, quão difícil será uma atualização.

Uma versão de correção de bug precisa preservar a compatibilidade binária, de origem e de serialização.

Versões menores significam coisas diferentes para projetos diferentes, mas geralmente elas não precisam preservar a compatibilidade da fonte.

Os principais números de versão podem quebrar as três formas.

Escrevi mais sobre a justificativa aqui .

Uma combinação de major, minor, patch, build, patch de segurança, etc.

Os dois primeiros são maiores e menores - o restante dependerá do projeto, da empresa e, às vezes, da comunidade. Em sistemas operacionais como o FreeBSD, você terá 1.9.0.1_number para representar um patch de segurança.

Depende um pouco da linguagem, Delphi e C #, por exemplo, têm significados diferentes.

Normalmente, os dois primeiros números representam uma versão principal e uma versão secundária, ou seja, 1.0 para a primeira versão real, 1.1 para algumas importantes correções de bugs e novos recursos menores, 2.0 para uma nova versão grande.

O terceiro número pode se referir a uma versão "realmente menor" ou revisão. 1.0.1 é apenas uma correção de bug muito pequena para 1.0.0, por exemplo. Mas também pode transportar o número de revisão do seu sistema de controle de origem ou um número sempre crescente que aumenta a cada compilação. Ou um Datestamp.

Um pouco mais detalhadamente aqui . "oficialmente", em .net, os quatro números são "Major.Minor.Build.Revision", enquanto em Delphi há "Major.Minor.Release.Build". Eu uso "Major.Minor.ReallyMinor.SubversionRev" para minhas versões.

Geralmente, o número está no formato version.major.minor.hotfix, não nos componentes internos individuais. Portanto, a v1.9.0.1 seria a versão 1, versão principal 9 (da v1), versão secundária (da v1.9) 0, hotfix 1 da (v1.9.0).

O primeiro número é normalmente chamado de número da versão principal. É basicamente usado para indicar mudanças significativas entre as compilações (ou seja, quando você adiciona muitos novos recursos, incrementa a versão principal). Componentes com diferentes versões principais do mesmo produto provavelmente não são compatíveis.

O próximo número é o número da versão secundária. Pode representar alguns novos recursos, ou várias correções de bugs ou pequenas alterações na arquitetura. Os componentes do mesmo produto, que diferem pelo número da versão secundária, podem ou não funcionar juntos e provavelmente não devem.

O próximo é geralmente chamado de número da compilação. Isso pode ser incrementado diariamente, ou com cada compilação "liberada" ou com cada compilação. Pode haver apenas pequenas diferenças entre dois componentes que diferem apenas no número da compilação e geralmente podem funcionar bem juntos.

O número final é geralmente o número da revisão. Muitas vezes, isso é usado por um processo de compilação automático ou quando você faz compilações descartáveis ​​"únicas" para teste.

Quando você incrementa os números de versão, você decide, mas eles sempre devem aumentar ou permanecer os mesmos . Todos os componentes podem compartilhar o mesmo número de versão ou incrementar apenas o número da versão nos componentes alterados.

O número da versão de um software complexo representa o pacote inteiro e é independente dos números de versão das partes. A versão 3.2.5 do Gizmo pode conter a versão 1.2.0 do Foo e a versão 9.5.4 da barra.

Ao criar números de versão, use-os da seguinte maneira:

1. O primeiro número é o release principal. Se você fizer alterações significativas na interface do usuário ou precisar interromper as interfaces existentes (para que seus usuários tenham que alterar o código da interface), vá para a nova versão principal.

2. O segundo número deve indicar que novos recursos foram adicionados ou que algo funciona de maneira diferente internamente. (Por exemplo, o banco de dados Oracle pode decidir usar uma estratégia diferente para recuperar dados, tornando a maioria das coisas mais rápidas e mais lentas.) As interfaces existentes devem continuar funcionando e a interface do usuário deve ser reconhecível.

3. A numeração das versões depende ainda da pessoa que está escrevendo o software - o Oracle usa cinco (!) Grupos, ie. uma versão do Oracle é algo como 10.1.3.0.5. Do terceiro grupo para baixo, você só deve introduzir correções ou pequenas alterações na funcionalidade.

os que variam menos seriam os dois primeiros, para major.minor, depois disso pode ser qualquer coisa, desde compilação, revisão, liberação a qualquer algoritmo personalizado (como em alguns produtos MS)

Cada organização / grupo tem seu próprio padrão. O importante é que você se atenha a qualquer notação que escolher, caso contrário seus clientes ficarão confusos. Dito isto, eu usei normalmente três números:

x.yz.bbbbb. Onde: x: é a versão principal (novos recursos principais) y: é o número da versão secundária (novos recursos pequenos, pequenas melhorias sem alterações na interface do usuário) z: é o service pack (basicamente o mesmo que xy, mas com algumas correções de erros): é o número da compilação e só é realmente visível na caixa "about" com outros detalhes para o suporte ao cliente. bbbb é de formato livre e todos os produtos podem usar seus próprios.

Aqui está o que usamos:

1. Primeiro número = era geral do sistema. Altera a cada dois anos e geralmente representa uma mudança fundamental na tecnologia, nos recursos do cliente ou em ambos.
2. Segundo número = revisão do esquema do banco de dados. Um incremento nesse número requer uma migração do banco de dados e, portanto, é uma alteração significativa (ou os sistemas são replicados e, portanto, alterar a estrutura do banco de dados requer um cuidadoso processo de atualização). Redefine para 0 se o primeiro número for alterado.
3. Terceiro número = somente alteração de software. Geralmente, isso pode ser implementado cliente por cliente, pois o esquema do banco de dados permanece inalterado. Redefine para zero se o segundo número for alterado.
4. Número da versão do Subversion. Nós o preenchemos automaticamente na compilação usando a ferramenta TortoiseSVN. Esse número nunca é redefinido, mas aumenta continuamente. Usando isso, sempre podemos recriar qualquer versão.

Este sistema está nos servindo bem, porque todo número tem uma função clara e importante. Vi outras equipes lidando com a questão do número principal / número menor (quão grande é a mudança) e não vejo o benefício disso. Se você não precisar acompanhar as revisões do banco de dados, basta acessar um número de versão de 3 ou 2 dígitos e facilitar a vida!

versão: v1.9.0.1

Onde-

. v é a abreviação de versão. Isso varia de empresa para empresa, dependendo da nomenclatura adotada em sua organização. Pode silenciar em alguma organização como 1.9.0.1

. 1 indica a versão principal, será atualizado sobre a modificação arquitetônica nas pilhas de aplicativos, infraestrutura (plataforma) ou interface de redes expostas

. 9 incates minor, será atualizado em atividades como adicionar novos componentes como interface do usuário, api, banco de dados etc; sob uma arquitetura específica

. 0 indica o recurso, será atualizado sobre quaisquer aprimoramentos nos componentes existentes (interface do usuário, api, banco de dados etc.)

. 1 indica o contador de construção em todas as fases principal, secundária e característica. Ele também inclui os hotfixes pós-produção.