Como fazer números de versão?

Minha empresa está construindo um produto. Vai ser versionado pelo SVN. É um aplicativo da web, então basicamente nunca haverá uma versão que não tenha alguns recursos e, portanto, sempre poderá ser rotulada como beta. Mas como será um produto corporativo, eu realmente não quero a "vigilância instável" lá. Então, como você lidaria com a versão? 1.0 é estável? A data da compilação deve estar no número da versão? Diga-me o que vocês pensam!

[ major ]. [ minor ]. [ release ]. [ build ]

major : Realmente uma decisão de marketing. Você está pronto para chamar a versão 1.0? A empresa considera esta uma versão principal para a qual os clientes podem ter que pagar mais, ou é uma atualização da versão principal atual que pode ser gratuita? Menos uma decisão de P&D e mais uma decisão de produto.

menor : inicia a partir de 0 sempre que maior é incrementado. +1 para cada versão que se torna pública.

release : toda vez que você atinge um marco no desenvolvimento e libera o produto, mesmo internamente (por exemplo, para o controle de qualidade), incrementa isso. Isso é especialmente importante para a comunicação entre equipes da organização. Escusado será dizer que nunca libere o mesmo 'release' duas vezes (mesmo internamente). Redefina para 0 em um ++ menor ou maior ++.

build : Pode ser uma revisão SVN, acho que funciona melhor.

Exemplos
Meu cromo atual: 83.0.4103.61

xyzg

incrementos em g são instáveis. (ou RCs) incrementos em z são estáveis ​​e com correções médias de erros.
incrementos em y são estáveis ​​e significam novos recursos.
incrementos em x são estáveis, versão principal sem 100% de compatibilidade com versões anteriores.

Certa vez, escrevi um elaborado "guia de estilo de versão" para um grande projeto meu. O projeto não se concretizou, mas o guia de estilo ainda está disponível online . É minha opinião pessoal, talvez seja útil (ou inspirador) para você.

Cuidado, é um texto longo, e vai para versões de componentes versus versões de produtos e coisas assim. Ele também expressa opiniões fortes sobre alguns esquemas de versão populares na comunidade OSS, mas eu os tenho, então os expresso. ;-)

Não concordo em usar o número de revisão do Subversion, por exemplo. Você pode querer manter uma versão lançada enquanto continua o desenvolvimento no TRUNK, para configurar uma ramificação de manutenção - e a versão do seu número de revisão diminui o ralo.

Editar: Como um resumo, ele distingue entre arquivos de origem, componentes e o produto em geral. Ele usa um sistema de autenticação xy separada para componentes e o produto, com uma boa interdependência entre os dois, tornando trivial o rastreamento de qual versão de componente pertence a qual versão de produto. Ele também fala sobre como lidar com os ciclos alfa / beta / release / patch sem interromper o sistema. Na verdade, é um modus operandi para todo o ciclo de desenvolvimento; portanto, você pode escolher. ;-)

Edit 2: Como muitas pessoas acharam meu artigo útil para fazer desta uma "Resposta agradável", comecei a trabalhar no artigo novamente. As versões PDF e LaTeX estão agora disponíveis, uma reescrita completa incluindo melhor linguagem e gráficos explicativos seguirá assim que eu encontrar o tempo. Obrigado por seus votos!

Inspire-se na Wikipedia: "Versão de software"

Outra opção "nova" e "relativamente popular" é a versão semântica

Resumo:

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 maneira compatível com versões anteriores e
3. PATCH versão quando você faz correções de erros 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.

abcd

Incrementos: quando
- d : correções de bugs
- c : manutenção, por exemplo, melhoria de desempenho
- b : novos recursos
- a : alteração na arquitetura

O obrigatório é o mais à esquerda, por exemplo, se houver, por exemplo, um novo recurso e um bug corrigido, você só precisará incrementar b .

Com base na minha experiência com o gerenciamento complexo de dependências no nível da plataforma corporativa e o versionamento de versões, vim recomendar uma abordagem que eu gostaria de chamar de Versão Semi-Semântica .

Basicamente, ele se baseia no Semantic Versioning 2.0, mas não é tão rigoroso.

Segmentos de versão semi-semântica:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Formato do segmento de versão principal:

MARKETTING.MAJOR.MINOR.PATCH

Cada segmento deve permitir alfanuméricos, mas números puros são recomendados para alterações incrementais lógicas.

Como o SemVer, recomendo os componentes Maior, Menor e Patch para representar camadas de compatibilidade reversa, mas também recomendo a adição de um componente de Marketing . Isso permite que os proprietários de produtos, grupos / épicos de recursos e preocupações comerciais colidam com o componente principal, independentemente das preocupações de compatibilidade técnica.

Diferentemente de outras respostas, não recomendo anexar um número de compilação ao segmento principal. Em vez disso, adicione um segmento pós-lançamento após um '+' (ex: 1.1.0.0 + build.42). O SemVer chama esses metadados de compilação, mas acho que o segmento pós-lançamento é mais claro. Esse segmento é ótimo para declarar os dados do sufixo como não relacionados às informações de compatibilidade no segmento de versão primário. Suas builds de integração contínua podem receber o número da versão anterior anexada com um número de build incremental que é redefinido após cada release principal (ex: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1) Algumas pessoas gostam de colocar o número de revisão svn aqui ou o git commit sha para facilitar a ligação ao repositório de códigos. Outra opção é usar o segmento pós-lançamento para hotfixes e patches, embora valha a pena considerar adicionar um novo componente de lançamento primário para isso. Ele sempre pode ser descartado quando o componente do patch é incrementado, pois as versões são efetivamente alinhadas à esquerda e classificadas.

Além dos segmentos de lançamento e pós-lançamento, as pessoas geralmente desejam usar um segmento de pré-lançamento para indicar pré-lançamentos quase estáveis, como alfas, betas e candidatos a lançamento. A abordagem do SemVer para isso funciona bem, mas eu recomendo separar os componentes numéricos dos classificadores alfanuméricos (por exemplo: 1.2.0.0 + alpha.2 ou 1.2.0.0 + RC.2). Normalmente, você deve aumentar o segmento de lançamento ao mesmo tempo em que adiciona o segmento pós-lançamento e, em seguida, solta o segmento de pré-lançamento quando você o supera no segmento de lançamento principal (ex: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Os segmentos de pré-lançamento são adicionados para indicar que a versão de lançamento está chegando, geralmente apenas um conjunto fixo de recursos para testes e compartilhamento mais aprofundados que não mudam minuto a minuto com base em mais confirmações.

A beleza de ter tudo isso definido semanticamente de uma maneira que cubra quase todos os casos de uso é que você pode analisá-los, classificar, comparar e incrementá-los de maneira padrão. Isso é especialmente importante ao usar sistemas de CI para aplicativos complexos com muitos componentes pequenos com versão independente (como microsserviços), cada um com suas próprias dependências gerenciadas.

Se você estiver interessado, escrevi um analisador semi-semântico em ruby . Eu precisava não apenas usar esse padrão, mas ser capaz de gerenciar outros aplicativos que o usavam.

"Números de versão" são uma questão para o seu sistema interno de controle de versão. Os números de versão são uma questão diferente (e devem ser mantidos diferentes).

Atenha-se a um sistema de versão MAJOR.MINOR simples (como v1.27), em que MAJOR é o nível de compatibilidade (a versão 2.x é incompatível com, ou pelo menos é muito diferente da versão 1.x), e MINOR é a versão de correções de bugs ou aprimoramentos menores . Desde que você siga o formato XY, também poderá usar outros sistemas como YEAR.MONTH (2009.12) ou YEAR.RELEASE (2009.3). Mas, na verdade, é melhor você seguir MAJOR.MINOR, a menos que tenha um bom motivo para não fazê-lo.

Definitivamente, não use nada que não se encaixe no formato XY, pois dificultará que distros, sites de anúncios etc. trabalhem com você, e isso por si só pode afetar seriamente a popularidade do seu projeto.

Use ramificações e tags em seu sistema de controle de versão (de preferência distribuído) para marcar números de versão internos específicos relacionados a MAJORS e MINORS, respectivamente.

E sim, 1.0 deve ser estável. Todas as versões devem ser estáveis, a menos que estejam marcadas como alfa, beta ou RC. Use Alphas para conhecido-quebrado-e-incompleto. Betas para conhecido-quebrado. RCs para "tente; você provavelmente encontrará coisas que perdemos". Qualquer coisa sem uma delas deve (idealmente, é claro) ser testada, conhecida como boa, ter um manual atualizado etc.

Hoje em dia é bastante popular usar apenas o número de revisão do Subversion.

Se estiver no SVN, por que não usar o número de revisão do SVN?

Se você olhar no canto inferior direito desta página da web, verá o número da versão Stack Overflow, que é o número de revisão do SVN.

O controle de versão depende de você; Eu colocaria 1.0 na primeira versão em que eu confiava. Você pode acompanhar rapidamente outras versões, já que alguns fornecedores de software deram uma má reputação à 1.0.

Você deseja alguma maneira de vincular o número da versão à versão exata usada, mas provavelmente deseja que seja agradável e simples para os usuários finais. Considere usar números de versão padrão e marcar o repositório SVN com o número da versão incluído.

Embora apenas seja agradável e simples acompanhar o número da revisão do Subversion, ele remove as informações do número da versão. Os usuários podem considerar isso uma coisa ruim.

Presumo que o seu aplicativo da web tenha algum tipo de procedimento de implantação, para que nem todas as revisões no Subversion sejam realmente publicadas. Como é impossível do "externo" (da perspectiva do usuário) determinar quando as versões estão sendo feitas e quantas revisões o código passará entre elas, isso torna os números quase aleatórios. Eles estarão aumentando, e acho que é possível supor algum tipo de distância da comparação de duas revisões, mas não muito.

Os números de versão clássicos tendem a "dramatizar" os lançamentos, para que os usuários possam criar algum tipo de expectativa. É mais fácil pensar "Eu tenho a versão 1.0, agora a versão 1.1 está adicionando isso e aquilo, isso parece interessante" do que pensar "ontem fizemos a revisão do SO 2587, hoje é 3233, deve ser muito melhor!".

É claro que essa dramatização também pode ser inflada, com as empresas escolhendo números de versão que parecem soar mais interessantes do que motivados pelas diferenças reais no produto, acho que indo um pouco com os contadores de revisão.

Esquema de versão: [principal]. [Menor]. [Devrel] [marca]
[principal]: incremente se você tiver uma mudança drástica no desenvolvimento.
[menor]: incremento se você tiver uma pequena alteração no desenvolvimento.
[devrel]: incrementa se você tiver uma correção de bug. Redefina para zero se maior ou menor ++.
[marca]: a, b ou rc: a é uma versão alfa, b é uma versão beta e rc é um candidato à liberação. Observe que versões como 1.3.57a ou 1.3.57b ou 1.3.57rc estão anteriores à versão 1.3.57. Comece em 0.0.0.

Passamos muito tempo decidindo quando incrementar a versão principal. Algumas lojas raramente fazem isso, então você tem lançamentos como 1.25.3 e outros o fazem para sempre, oferecendo 15.0

Eu me cansei disso e convenci a todos de que o número principal de lançamentos é apenas o ano e o menor é apenas um lançamento seqüencial dentro do ano. Os usuários pareciam gostar e é fácil descobrir o número da próxima versão.

Year.Release.build

• ano = ano atual
• release = número de sequência de lançamentos públicos com nova funcionalidade - redefinir para 1 a cada ano
• build = incrementado para correções de erros e versões internas

EDITAR

** Agora, isso era para um aplicativo interno aprimorado continuamente **

Provavelmente isso não funcionaria para aplicativos comerciais, onde é importante ter grandes lançamentos em diferentes épocas do ano para fins de marketing e financeiros.

A razão pela qual essa pergunta existe é porque não temos uma maneira acordada de fazer o gerenciamento de configurações.

A maneira como eu gosto de fazer o número da versão é apenas incrementar o número inteiro 1. Não quero um número de versão com várias partes que precisarei explicar ou documentar. E eu não quero usar o número de rev SVN, pois isso exigirá algumas explicações também.

Você precisaria de alguns scripts de versão no SVN para fazer isso acontecer

Tenho muito pouca experiência na área. No entanto, aqui está o que eu faria:

1. Escolha um esquema para numerar revisões e cumpri-lo. Ser consistente.
2. Cada alteração de versão deve representar uma alteração significativa . Quão pequena é uma alteração significativa e os níveis de alteração refletidos no número da versão dependem de você.

Obviamente, você pode simplesmente usar o número de revisão do svn --- como muitos outros sugeriram !!!

Eu espero que isso ajude.

Usamos uma sintaxe simples major.minor.julian_date.

Onde;

• major - O primeiro lançamento é 1 e, quando introduzimos novos recursos ou alterações tão significativos que não são compatíveis com versões anteriores, aumentamos esse número.
• minor - Os principais lançamentos importantes. Para cada construção promovida pela produção, esse número aumenta.
• julian_date - o dia juliano em que a compilação foi enviada ao controle de qualidade.

O exemplo da primeira versão enviada para o controle de qualidade em 1/15 é -> 1.0.015 O
exemplo da primeira versão enviada para a produção em 3/4 é -> 1.1.063

Não é perfeito, mas útil, pois enviamos as compilações para o controle de qualidade quase diariamente.

Algumas boas informações aqui:

Quando alterar versões de arquivo / montagem

Antes de tudo, as versões de arquivo e de montagem não precisam coincidir entre si. Eu recomendo que as versões dos arquivos sejam alteradas a cada compilação. Mas não altere as versões de montagem a cada compilação, apenas para saber a diferença entre duas versões do mesmo arquivo; use a versão do arquivo para isso. Decidir quando alterar as versões de montagem leva alguma discussão sobre os tipos de construções a serem consideradas: remessa e não remessa.

Construções que não são de expedição Em geral, recomendo manter as versões de montagem que não são de expedição iguais entre as construções de expedição. Isso evita problemas de carregamento de assembly com nomes fortes devido a incompatibilidades de versão. Algumas pessoas preferem usar a política do editor para redirecionar novas versões de montagem para cada build. No entanto, recomendo isso para compilações que não sejam de remessa: isso não evita todos os problemas de carregamento. Por exemplo, se um parceiro copia seu aplicativo x, talvez ele não saiba instalar a política do editor. Em seguida, seu aplicativo será quebrado por eles, mesmo que funcione perfeitamente em sua máquina.

Porém, se houver casos em que aplicativos diferentes na mesma máquina precisem vincular-se a versões diferentes do seu assembly, recomendo fornecer a esses compiladores versões diferentes do assembly, para que o correto para cada aplicativo possa ser usado sem a necessidade de usar o LoadFrom / etc.

Compilações de remessa Para saber se é uma boa ideia alterar essa versão para compilações de remessa, isso depende de como você deseja que a ligação funcione para os usuários finais. Deseja que essas compilações estejam lado a lado ou no local? Há muitas mudanças entre as duas compilações? Eles vão quebrar alguns clientes? Você se importa com isso (ou deseja forçar os usuários a usar suas atualizações importantes)? Se sim, considere incrementar a versão do assembly. Mas, novamente, considere que fazer isso muitas vezes pode desarrumar o disco do usuário com montagens desatualizadas.

Quando você altera as versões do assembly Para alterar as versões codificadas para a nova, recomendo definir uma variável para a versão em um arquivo de cabeçalho e substituir o código nas fontes pela variável. Em seguida, execute um pré-processador durante a compilação para colocar a versão correta. Eu recomendo alterar as versões logo após o envio, não antes, para que haja mais tempo para detectar bugs devido à alteração.

Ou, para usar o número da versão "pensada", número de subversão por vírgula. ZB:

1.0.101 // revisão 101, versão

ou 1.0.101-090303 // com data de lançamento, eu uso este