Como os números de versões anteriores funcionam para novos produtos?

Atualmente, estou escrevendo um pequeno aplicativo de desktop para um amigo, mas estou fazendo isso principalmente como uma experiência de aprendizado para mim. No espírito de ser educado e fazer as coisas da maneira certa, quero ter números de versão para este aplicativo.

Minha pesquisa trouxe esses resultados relacionados

• Que "convenção de nomenclatura de versão" você usa?
• Como você versão seus arquivos (números de versão)
• Bifurcou um projeto, onde meus números de versão começam?

mas nenhum deles aborda a numeração de alfas, betas, candidatos a liberação etc. Quais são as convenções para números de versão abaixo de 1.0? Eu sei que eles podem continuar por algum tempo; por exemplo, o PuTTY existe há pelo menos uma década e ainda está apenas na versão beta 0.60.

Realmente depende do projeto; alguns projetos nem lançam a versão 1.0.

Os desenvolvedores do MAME não pretendem lançar uma versão 1.0 do seu programa emulador. O argumento é que nunca será realmente "terminado" porque sempre haverá mais jogos de arcade. A versão 0.99 foi simplesmente seguida pela versão 0.100 (versão secundária 100> 99). De maneira semelhante, o Xfire 1.99 foi seguido por 1.100. Após 6 anos de desenvolvimento, o eMule ainda nem chegou à versão 0.50. ^{Versão de software na Wikipedia}

Um método popular de numerar versões (que eu comecei a usar) é o Semantic Versioning .

Sob esse esquema, os números de versão e a maneira como eles mudam transmitem significado sobre o código subjacente e o que foi modificado de uma versão para a seguinte.

Algumas citações para fornecer mais idéias sobre como funciona e / ou responder a algumas de suas perguntas:

Como sei quando lançar a 1.0.0?

Se o seu software estiver sendo usado na produção, provavelmente já deve ser o 1.0.0. Se você possui uma API estável da qual os usuários dependem, você deve ser 1.0.0. Se você está preocupado com a compatibilidade com versões anteriores, provavelmente já deve ser o 1.0.0.

Isso não desencoraja o desenvolvimento rápido e a iteração rápida?

A versão principal zero é sobre desenvolvimento rápido. Se você estiver alterando a API todos os dias, ainda deverá estar na versão 0.xx ou em um ramo de desenvolvimento separado, trabalhando na próxima versão principal.

Se mesmo as menores alterações incompatíveis com a versão anterior da API pública exigirem um grande aumento de versão, não terminarei na versão 42.0.0 muito rapidamente?

Esta é uma questão de desenvolvimento responsável e previsão. Alterações incompatíveis não devem ser levemente introduzidas em softwares com muito código dependente. O custo que deve ser incorrido para atualizar pode ser significativo. Ter que fazer uma versão superior das versões principais para liberar alterações incompatíveis significa que você pensará no impacto de suas alterações e avaliará a relação custo / benefício envolvida.

Também existem regras sobre como especificar versões "alfa", "beta" etc. etc. Confira os detalhes em http://semver.org/ .

[Editar] Outro esquema interessante de numeração de versões é o que o MongoDB usa :

O MongoDB usa versões com números ímpares para lançamentos de desenvolvimento.

Existem 3 números em uma versão do MongoDB: ABC

• A é a versão principal. Isso raramente muda e significa mudanças muito grandes
• B é o número da liberação. Isso incluirá muitas alterações, incluindo recursos e coisas que podem quebrar a compatibilidade com versões anteriores. Até Bs serão ramos estáveis ​​e Bs ímpares serão desenvolvimento.
• C é o número da revisão e será usado para erros e problemas de segurança.

Por exemplo:

• 1.0.0: primeira versão do GA
• 1.0.x: correções de bug para 1.0.x - altamente recomendado para atualização, muito pouco risco
• 1.1.x: versão de desenvolvimento. isso incluirá novos recursos que não estão totalmente concluídos e obras em andamento. Algumas coisas podem ser diferentes de 1.0
• 1.2.x: segunda versão do GA. este será o culminar da versão 1.1.x.

Eu não acho que exista um "padrão" como tal.

Existe uma convenção para Candidatos a Liberação que geralmente é "[versão] RC 1" etc. etc., dependendo de quantas versões você acha que pode lançar.

Se você estiver lançando uma versão muito antiga do seu produto - uma que não é totalmente concluída -, convém usar a versão "0". Dessa forma, você pode incrementar a versão ao longo do tempo à medida que preenche seu conjunto de recursos.

Eu usaria "Alpha" e "Beta" como Release Candidate - para versões com tempo limitado para indicar que você acha que está prestes a lançar a versão completa.

Há uma página da Wikipedia sobre versão de software . Para compartilhar versões anteriores à 1.0, a convenção usada pela Apple e outras pessoas funciona bem: major.minor.maintSrev, em que S é o indicador de estágio para versões de pré-lançamento: d = desenvolvimento, a = alfa, b = beta, rc = candidato a lançamento. Portanto, sua primeira versão interna pode ser 1.0.0d1.

Para revisões completamente internas, o registro de data e hora é suficiente.

Cada desenvolvedor geralmente decide qual padrão usará. Em geral, embora os números à esquerda da vírgula decimal indiquem grandes revisões que provavelmente seriam muito visíveis para o usuário médio (ou seja, alterações de funcionalidade ou interface, etc.). No lado direito do ponto decimal, isso seria uma alteração / modificação / adição que não mudou muito a funcionalidade geral e o design, mas mudou algo sobre o próprio programa (por exemplo, tornar a função mais rápida enquanto ainda faz a mesma coisa ou corrige um problema de segurança). Então, se você adicionar pontos decimais adicionais, os números à direita indicariam mudanças cada vez menores (por exemplo, pequenas correções de bugs / problemas de segurança e outros).

Como outros já disseram, não parece haver um padrão exato. Nossa organização usa a seguinte notação:

Versão 1.0 ---> 2.0 (Um importante recurso novo / aprimorado adicionado ao produto)

Versão 1.0 ---> 1.1 (Um recurso novo / aprimorado de nível médio adicionado ao produto)

Versão 1.0 ---> 1.001 (Correções de bugs)

O marco da "versão 1.0" é muito importante para usuários experientes de computadores, pois implica que o programa está pronto e funciona conforme o esperado. Qualquer coisa na versão "0. algo" implica que os próprios programadores pensam que o programa ainda não foi concluído .

Você pode manter os números de versão "0.1", "0.2" ... para obter as principais realizações de funcionalidade e, em seguida, subconjuntá-lo com um número de compilação que freqüentemente é uma data e um carimbo de data e hora com granulação suficiente.