Como fazer números de versão?

https://stackoverflow.com/questions/615227

03-07-2019
|

Pergunta

Minha empresa está construindo um produto. Vai ser versionadas por SVN. É um webapp então basicamente nunca haverá um para fora a versão que não tem algumas características em si e, portanto, poderia ser sempre rotulado como beta. Mas, uma vez que vai ser um produto corporativo eu realmente não quer que o "watchout instável" lá. Então, como você iria sobre controle de versão? É de 1,0 estável? Caso a data de construção estar no número da versão? Diga-me o que vocês pensam!

Solução

[ importante ]. [ menor ]. [ versão ]. [ construção ]

importante : Realmente uma decisão de marketing. Você está pronto para chamar a versão 1.0? Será que a empresa considere esta uma versão principal para que os clientes pode ter que pagar mais, ou é uma atualização da versão atual principal que pode ser livre? Menos de uma decisão de R & D e mais uma decisão do produto.

menor : Começa a partir 0 sempre que importante é incrementado. +1 para cada versão que vem a público.

versão : Cada vez que você atingiu um marco de desenvolvimento e liberar o produto, mesmo internamente (por exemplo, a QA), incrementar este. Isto é especialmente importante para a comunicação entre as equipes na organização. Escusado será dizer que nunca mais soltar a mesma 'libertação' duas vezes (mesmo internamente). Repor a 0 em cima menor ++ ou grande ++.

construção :. Pode ser uma revisão do SVN, eu acho que funciona melhor

Outras dicas

x.y.z.g

incrementos em g são instáveis. (Ou CRs) incrementos em z são estáveis ??e de bugs média correções.
incrementos em y são estáveis ??e novos recursos médios.
incrementos em x é maior libertação estável, sem 100% de compatibilidade para trás.

Uma vez eu escrevi um elaborado "guia de estilo de versões" para um grande projeto da mina. O projeto não se concretizou, mas o guia de estilo é ainda disponíveis online. É minha opinião pessoal, talvez seja útil (ou inspiração) para você.

Cuidado, é um texto longo, e entra em versões do produto componente de versões vs. e coisas assim. Ele também expressa opiniões fortes sobre alguns esquemas de versões populares na comunidade OSS, mas eu tê-los, então eu expressá-las. ; -)

Eu discordo usando o número de revisão do Subversion, por exemplo. Você pode querer manter um versão lançada, continuando o desenvolvimento no tronco, de forma que você configurar um ramo de manutenção -. E o seu número de revisão de versões vai pelo ralo

Editar: Como um resumo, distingue entre versões arquivos de origem, componentes e do produto global. Ele usa um sistema de X.Y separado versoning para componentes e do produto, com um bom interdependência entre os dois que faz rastreamento qual versão componente pertence a qual versão do produto trivial. Também fala sobre como lidar com os ciclos de alfa / beta / libertação / remendo sem quebrar o sistema. Na verdade, é um modus operandi para todo o ciclo de desenvolvimento, de modo que você pode querer cherry-pick. ; -)

Editar 2: Como as pessoas o suficiente encontrou meu artigo útil para tornar este um "Nice Resposta", eu comecei a trabalhar no artigo novamente. As versões em PDF e LaTeX estão agora disponíveis, uma reescrita completa incluindo melhor linguagem e gráficos explicativos seguirão assim que pode encontrar o tempo. Obrigado por seus votos!

Arranja alguma inspiração de Wikipedia: "Software de versão"

Outro "novo" e "relativamente popular" opção é Semântica Versioning

Resumo:

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

versão principal quando você faz alterações incompatíveis API,

versão secundária quando você adicionar a funcionalidade de uma forma compatível com versões anteriores, e

versão do patch quando você faz correções de bugs compatível com versões anteriores.

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

a.b.c.d

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

O obrigatório é a mais deixou um exemplo se houver, por exemplo, um novo recurso e um bug corrigido, então você só tem que incremento b .

Com base na minha experiência com gerenciamento de dependência nível da plataforma empresa complexa e liberar versões Vim para recomendar uma abordagem que eu gosto de chamar de Semi-Semântica Versioning .

Basicamente constrói fora do Semântica Versioning 2,0 mas não é tão rigoroso.

Semi-semânticas Versão Segmentos:

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

Primária Lançamento Formato Segmento:

MARKETTING.MAJOR.MINOR.PATCH

Cada segmento deve permitir alfanuméricos, mas numéricos puros são recomendados para mudanças incrementais lógicas.

Como SemVer, eu recomendo componentes maiores, menores, e patch para representar níveis de compatibilidade reversa, mas eu recomendo também prepending um componente MERCADO . Isso permite que os proprietários do produto, épicos característica / grupos e interesses de negócio para bater o independente componente principal das preocupações de compatibilidade técnica.

Ao contrário de outras respostas, eu não recomendado acrescentar um número de compilação para o segmento primário. Em vez disso, adicione um segmento pós-lançamento na sequência de um '+' (ex: 1.1.0.0 + build.42). SemVer chama isso de metadados de construção, mas acho segmento pós-lançamento é mais clara. Este segmento é grande para declarar os dados sufixo como não relacionado às informações de compatibilidade no Segmento primário lançamento . Sua integração contínua constrói pode então ser dado o número versão anterior anexado com um número de compilação incremental que redefine após cada lançamento primário (ex: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Algumas pessoas alternadamente como para colocar o número de revisão svn aqui ou o git commit sha para torná-lo fácil de empate para o repositório de código. Outra opção é usar o segmento pós-lançamento para hotfixes e patches, tho pode valer a pena considerando a adição de um novo componente liberação principal para isso. Ele sempre pode obter caiu quando o componente patch é incrementado, já que as versões são efetivamente alinhados à esquerda e ordenadas.

Além dos segmentos de lançamento e pós-lançamento, as pessoas muitas vezes querem usar um Segmento Pre-Release para indicar pré-lançamentos quase-estáveis ??como alfas, betas e release candidates. A abordagem SemVer para isso funciona bem, mas eu recomendo que separa os componentes numéricos de classificadores alfa-numérico (ex: 1.2.0.0 + alpha.2 ou 1.2.0.0 + RC.2). Normalmente, que se bata com o segmento de libertação, ao mesmo tempo que a adição do segmento pós-lançamento e, em seguida, solte o segmento pré-lançamento da próxima vez que danificá-las segmento de libertação primário (ex: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). segmentos de pré-lançamento são adicionados para indicar que a versão está chegando, geralmente apenas um conjunto fixo de recursos para mais testes em profundidade e de partilha que não muda minuto a minuto com base em mais commits.

A beleza de ter tudo isso semanticamente definido de uma forma que cobre quase todos os casos de uso é que você pode analisar, classificar, comparar e incrementar-los de uma forma padrão. Isto é especialmente importante ao utilizar os sistemas CI para aplicações complexas com lotes de pequenos componentes de versão independente (como micro-serviços) cada um com suas próprias dependências gerenciados.

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

"Os números de versão" são uma questão para o seu sistema de controle de versão interno. números de versão são uma questão diferente (e deve ser mantido diferente).

furar a um sistema simples liberação MAJOR.MINOR (como v1.27), onde MAJOR é o nível de compatibilidade (versão 2.x é incompatível com ou pelo menos majorly diferente da versão 1.x) e MINOR é seus lançamentos bugfix ou pequenas melhorias. Contanto que você siga o formato X.Y, você também pode usar outros sistemas como YEAR.MONTH (2.009,12) ou YEAR.RELEASE (2009.3). Mas realmente você provavelmente está melhor furar a MAJOR.MINOR menos que você tenha uma boa razão para não.

Definitivamente não usar qualquer coisa que não se encaixa no formato XY, como ele vai torná-lo difícil para distros, sites anúncio, etc para trabalhar com você, e que por si só poderia afetar seriamente a popularidade do seu projeto.

Use as ramificações e marcas em seu sistema (de preferência distribuído) de controle de versão para marcar números de versão interno específicos, relacionados com maiores e menores, respectivamente.

E sim, 1.0 deve ser estável. Todos os lançamentos deve ser estável, a menos que estejam marcados alfa, beta ou RC. Utilização alfas para conhecido-quebrado-e-incompleta. Betas para conhecido-quebrado. RCs para "experimentá-lo, você provavelmente vai manchar as coisas que perdemos". Qualquer coisa sem um desses deve (idealmente, é claro) ser testado, de boa conhecido, tem um up o manual data, etc.

É bastante popular nos dias de hoje usar apenas o número de revisão Subversion.

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

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

Versioning é com você; Eu ia colocar 1,0 na primeira versão que eu estava confiante. Você pode querer segui-lo rapidamente com outras versões, já que alguns fornecedores de software têm dado 1.0 uma má reputação.

Você quer alguma forma de amarrar o número da versão para a construção exata usada, mas você provavelmente quer que ele seja agradável e simples para seus usuários finais. Considere o uso de números de versão padrão, e marcar o repositório SVN com o número da versão incluído.

Enquanto apenas indo com o número de revisão Subversion é agradável e simples, ele faz informações remove a partir do número da versão. Os usuários podem considerar isso uma coisa ruim.

Eu supor que seu webapp terá algum tipo de procedimento de implantação, de modo que não cada revisão no Subversion é realmente publicado. Uma vez que é impossível "de fora" (do ponto de vista do usuário) para determinar quando as liberações estão sendo feitas, e quantas revisões do código vai sofrer entre eles, faz os números quase aleatória. Eles serão cada vez maior, e eu acho que é possível suposição alguns tipo de distância comparando duas revisões, mas não muito.

números de versão clássicos tendem a releases "dramatizar", de modo que os usuários podem construir algum tipo de expectativa. É mais fácil pensar "Eu tenho a versão 1.0, agora a versão 1.1 está fora adicionando isto e aquilo, que parece interessante" do que pensar "ontem nós correu SO revisão 2587, hoje é 3233, deve ser muito melhor!".

É claro que essa dramatização pode ser inflado também, com as empresas que escolhem os números de versão que se destinam a soar mais interessante do que é motivada pelas diferenças reais no produto, eu acho que vai com os contadores número de revisão isso um pouco.

esquema

Versão:.. [grande] [menor] [devrel] [marca]
[Principal]:. Incremento se você tiver uma mudança drástica no desenvolvimento
[Menor]: incremento se você tem uma pequena alteração no desenvolvimento
. [Devrel]: incremento se você tiver uma correção de bug. Repor a zero se importante ++ ou menor ++.
[Marca]: a, b ou rc: uma é uma versão alfa, b é versão beta, e Rc é um candidato libertação. Note-se que versões como 1.3.57a ou 1.3.57b ou 1.3.57rc é antes da versão 1.3.57. Comece no 0.0.0.

Nós passado maneira muito tempo decidir quando incrementar a versão principal. Algumas lojas raramente iria fazê-lo assim que você teria lançamentos como 1.25.3 e outros iria fazê-lo para sempre liberar dando-lhe 15,0

I got alimentado com isso e convenceu a todos o maior número de versão é apenas o ano eo menor é apenas uma liberação seqüencial dentro do ano. Os usuários parecia gostar e é um acéfalo para vir para cima com o próximo número da versão.

Year.Release.build

ano = ano em curso
liberação = seqüência # de lançamentos públicos com nova funcionalidade - redefinido para 1 cada ano
build = incrementado para bug correções e lançamentos internos

Editar

** Agora, este foi para uma aplicação interna que foi continuamente reforçada **

Este provavelmente não trabalho para aplicações comerciais onde é importante ter grandes lançamentos em diferentes épocas do ano para fins de marketing e financeiros.

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

Escolha um esquema de numeração revisões e cumpri-lo. Ser consistente.
Cada mudança de versão deve representar uma mudança significativa . Como pequeno uma mudança é significativa e os níveis de mudança que se refletem no número da versão são até você.

Claro, você pode simplesmente usar o número svn revisão --- como muitos outros têm sugerido !!!

Espero que isso ajude.

A razão por que existe esta pergunta é porque não temos um único acordado maneira de fazer gestão de configuração.

A maneira que eu gostaria de fazer o número da versão é inteiro apenas incremento de 1. Eu não quero um número de multi versão parte que eu vou ter de explicar ou documento. E eu não quero usar o número rev SVN como que vai exigir alguma explicação bem.

Você precisaria de alguns scripts em cima do SVN libertação para que isso aconteça

Nós usamos uma sintaxe major.minor.julian_date simples.

Onde;

grande -. Primeira versão é 1 e, em seguida, quando introduzimos principais novos recursos ou muda tão significativa que não são compatíveis com versões anteriores aumento este número
menor - Os principais lançamentos marcantes. Para cada construção empurrado por produção este número aumenta.
julian_date - A Julian Day a compilação foi empurrado para QA.

Exemplo do primeiro lançamento empurrado para QA no 1/15 é -> 1.0.015
Exemplo da primeira versão empurrado para Produção em 3/4 é -> 1.1.063

Não é perfeito, mas acessível como nós empurramos constrói a QA próximo dia.

Algumas boas informações aqui:

quando mudar Arquivo / Versões de montagem

Em primeiro lugar, as versões de arquivos e versões de montagem não precisa coincidir com o outro. Eu recomendo que a mudança versões de arquivos com cada compilação. Mas, não altere montagem versões com cada compilação apenas para que você pode dizer a diferença entre duas versões do mesmo arquivo; usar a versão do arquivo para isso. Decidir quando mudar de montagem versões toma alguma discussão sobre os tipos de compilações a considerar: o transporte e não-transporte.

Não-envio Constrói Em geral, eu recomendo manter não-distribuiam versões de montagem do mesmo entre o transporte constrói. Isso evita fortemente nomeado assembly carregar problemas devido a incompatibilidades versão. Algumas pessoas preferem usar política de editor para redirecionar novas versões de montagem para cada construção. Eu recomendo contra isso para não-transporte constrói, no entanto: ele não evitar todos os problemas de carregamento. Por exemplo, se um parceiro-x cópias seu aplicativo, eles podem não saber para instalar política de editor. Em seguida, o aplicativo será quebrado para eles, mesmo que ele funciona muito bem em sua máquina.

Mas, se há casos em que diferentes aplicações no mesmo necessidade máquina para se ligam a diferentes versões do seu conjunto, eu recomendo dar aqueles constrói diferentes versões de montagem de modo a que o correto para cada aplicativo pode ser usado sem ter que usar LoadFrom / etc.

Shipping Constrói Quanto a saber se é uma boa idéia para mudar essa versão para o transporte constrói, isso depende de como você deseja que a ligação ao trabalho para os usuários finais. Quer estes constrói estar lado-a-lado ou no local? Existem muitas mudanças entre as duas versões? eles estão indo para quebrar alguns clientes? Você se importa que ele quebra-los (ou você quer forçar os usuários a usar suas atualizações importantes)? Se sim, você deve considerar incrementar a versão de montagem. Mas, novamente, considere que fazer isso muitas vezes pode ninhada rígido do usuário com montagens desatualizados.

Quando você mudar de versões de montagem Para alterar versões codificado para o novo, eu recomendo definindo uma variável para a versão em um arquivo de cabeçalho e substituindo o hardcode em fontes com a variável. Em seguida, execute um pré-processador durante a construção para colocar na versão correta. Eu recomendo mudar versões direita após o envio, não imediatamente antes, de modo que não há mais tempo para erros de captura devido à mudança.

Ou, para usar o seu 'pensamento' número da versão número vírgula subversão .. z.B:.

1.0.101 // revisão 101, versão

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

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow