Qual é exatamente o número da compilação em MAJOR.MINOR.BUILDNUMBER.REVISION

Nunca vi isso escrito dessa forma. Onde eu trabalho, usamos o formulário MAJOR.MINOR.REVISION.BUILDNUMBER, onde:

• MAJOR é uma versão principal (geralmente muitos novos recursos ou alterações na interface do usuário ou SO subjacente)
• MINOR é uma versão secundária (talvez alguns novos recursos) em uma versão principal anterior
• REVISION é geralmente uma correção para uma versão secundária anterior (sem novas funcionalidades)
• BUILDNUMBER é incrementado para cada versão mais recente de uma revisão.

Por exemplo, uma revisão pode ser lançada para QA (controle de qualidade), e eles voltam com um problema que requer uma mudança. O bug seria corrigido e devolvido ao controle de qualidade com o mesmo número de REVISÃO, mas um BUILDNUMBER incrementado.

Comentários

• +1: Isso ‘ é praticamente da mesma forma que ‘ vi em todos os outros lugares também. Eu ‘ vi e gostei como algumas empresas usam apenas um carimbo de data / hora para BUILDNUMBER.
• +1: O ” MAJOR.MINOR.REVISION.BUILDNUMBER ” forma é compreensível e faz sentido. Eu vi o formulário BUILDNUMBER.REVISION no site do MSDN (link atualizado em questão) e me confundiu totalmente.
• Estranho. Eu esperaria que a última revisão fizesse mais sentido – é ‘ o número que (provavelmente) mudará mais.
• @Izkata, na verdade, a compilação O número muda mais, pelo menos a forma como o usamos no meu contrato principal agora, que usa controle de versão estrito porque estamos fazendo dispositivos médicos. Uma revisão atualizada indica que houve uma correção para o software anterior, que precisa ser testado pelo QA (Quality Assurance). Este é um departamento completamente separado que faz testes extensivos por três dias (de acordo com as diretrizes do FDA). Se eles encontrarem algum problema, então alterações adicionais no código podem ser necessárias, exigindo uma nova compilação (recompilar e vincular) e, em seguida, testar novamente, mas o número de revisão permanece o mesmo.
• @tcrosley Acho que ‘ é um caso de terminologia pouco clara. Eu estava pensando em revisões no controle de versão.

Toda a confusão vem do semânticas diferentes que a MS usa para “Número de compilação” e especialmente “Revisão”. Os termos significam coisas diferentes.

A maioria das pessoas (inclusive eu) usa um esquema de numeração de versão semântica em que você obtém um número BUILD maior sempre que você precisar fazer uma nova construção por qualquer motivo. Para nós, um hotfix é considerado apenas mais uma mudança de código, e a parte BUILD aumenta automaticamente a cada execução de CI. Módulos com o mesmo MAJ.MIN.REV são considerados intercambiáveis, e o BUILD informa qual é o mais recente.

Incrementar REVISION, entretanto, indica um novo branch de lançamento permanente, é por isso que o colocamos antes de BUILD.A desvantagem dessa abordagem é que podemos obter a seguinte sequência de eventos:

• commit número 4711: Alice adicionou o recurso A
• CI produz a compilação 1.2.3.100
• número do commit 4712: Bob modificou o recurso B
• número do commit 4713: Alice corrigiu o recurso A (o “hotfix”)
• CI produz a compilação 1.2.3.101

Como você pode ver, o hotfix não é a única mudança contida no próximo , as modificações de Bob também se tornam parte dessa construção. Se você quiser estabilizar o branch atual, poderá ter problemas, pois nunca poderá ter certeza se Bob acabou de adicionar um monte de bugs ou não.

MS usa os dois termos de maneira diferente. O número BUILD não é incrementado automaticamente, em vez disso, pode ser considerado uma espécie de branch de lançamento, para congelar o código usado para uma versão específica do código. A REVISION indica mudanças “importantes” adicionais aplicadas a esse branch BUILD. A sequência seria, portanto, a seguinte:

• número do commit 4711: Alice adicionou o recurso A ao tronco / mestre
• Carl cria ramo de compilação 1.2.100
• CI produz compilação 1.2.100.0
• número do commit 4712: Bob modificou o recurso B no tronco / master
• número do commit 4713: Alice corrigiu o recurso A no 1.2.100 branch
• CI produz build 1.2.100.1

O termo REVISÃO pode se referir a

• um produto revisão (é assim que a maioria das pessoas usa)
• uma revisão de uma compilação diária (é isso que a MS faz)

A principal diferença entre os dois processos é se você deseja ou não a capacidade de aplicar hotfixes a compilações de CI e, portanto, em que ponto do processo a ramificação é feita. Esse aspecto se torna importante quando você deseja poder escolher uma determinada construção a qualquer momento depois que todos os testes foram bem-sucedidos e promover exatamente essa versão para o próximo lançamento oficial de seu produto.

No nosso caso, a ferramenta CI cria uma tag de repositório, para que sempre tenhamos as informações necessárias prontas para usar, quando necessário. Com o SVN fica ainda mais simples, porque as tags e branches são implementados exatamente da mesma maneira – uma tag nada mais é do que um branch localizado em /tags.

Veja também

Da seção FAQ em Estratégia de ramificação do TFS :

Em que branch devo consertar o tíquete P1 (hotfix)?

• O P1 deve ser corrigido no branch que está mais próximo da base de código em produção. Nesse caso, o P1 deve ser corrigido no branch Prod. Ao aplicar a correção em qualquer outro branch e lançar as mudanças para a produção, você corre o risco de liberar código semiacabado ou não testado das iterações subsequentes.

• Agora você pode argumentar se é seguro para trabalhar diretamente contra o branch Prod, pense novamente, um P1 que requer atenção imediata não deve ser um problema fundamental no sistema. Caso seja um problema fundamental, ele deve ser adicionado ao backlog do produto, pois pode exigir uma análise e discussão adicionais com o cliente.

Outra boa leitura é o guia de ramificação do TFS

Comentários

• Esta é uma ótima resposta! +1

A Microsoft descreve a finalidade de cada componente de um número de versão .NET em sua documentação MSDN para a classe Version. Aqui está a parte relevante:

major.minor [.build [.revision]]

Os componentes são usados por convenção como segue:

Principal: Assemblies com o mesmo nome, mas diferentes versões principais não são intercambiáveis. Um número de versão superior pode indicar uma reescrita principal de um produto em que a compatibilidade com versões anteriores não pode ser assumida.

Secundário: se o nome e o número da versão principal em dois assemblies forem iguais, mas o número da versão secundária for diferente, isso indica um aprimoramento significativo com a intenção de compatibilidade com versões anteriores. Este número de versão secundária mais alto pode indicar um lançamento pontual de um produto ou uma nova versão totalmente compatível com versões anteriores de um produto.

Compilação: uma diferença no número de compilação representa uma recompilação da mesma fonte. Diferentes números de compilação podem ser usados quando o processador, plataforma ou compilador muda.

Revisão: Assemblies com o mesmo nome, números de versão principal e secundária, mas revisões diferentes devem ser totalmente intercambiáveis. Um número de revisão maior pode ser usado em uma construção que corrige uma falha de segurança em uma montagem lançada anteriormente.

http://msdn.microsoft.com/en-us/library/system.version.aspx

Comentários

• Fico perplexo porque ninguém conhece esse padrão, cada resposta aqui afirma que a compilação vai no final e não ‘ para entender que a revisão é muito simples; significa hotfix. Você libera uma versão e, em seguida, cria outras versões, mas quando tem que voltar e consertar essa versão, você atualiza a revisão para mostrar que a versão específica que foi lançada foi alterada para uma nova versão
• +1 para uma resposta que tem um número de compilação justificável. Meramente incrementar o número é inútil se a revisão permanecer a mesma (a menos que você tenha um sistema de compilação insano que depende do tempo). Usar o número da compilação para sinalizar qual compilador, plataformas etc. é útil.
• Build como um recompilation of the same source parece ser um ponto importante que se esquece. Se ‘ uma mudança de código (isso não ‘ requer um novo aumento Principal / Menor inteiro), então o Revision também deve ser alterado.
• @PeterX Como no caso de alterações específicas de compilação ao redirecionar?
• ” Uma diferença no número de compilação representa uma recompilação da mesma fonte ” parece contradizer a documentação. Depois de fazer uma revisão, não é mais a mesma fonte. Ter BUILD antes de REVISION faz sentido apenas se uma revisão for específica para uma construção que representa uma ” alteração de processador, plataforma ou compilador “. Então eu acho que o que a maioria vê como um aumento de REVISÃO deve realmente ser um impacto MENOR ao usar essas descrições. Embora os documentos mencionem o uso de REVISION para hotfix, mas eu suponho que os hotfix se apliquem a todas as compilações e, portanto, devem ser um impacto MINOR. Eu só quero alguma consistência lógica !!

Há pelo menos algumas coisas diferentes que eu poderia imagine a referência do número da compilação:

1. Versão de controle de origem que foi lançada. Por exemplo, se houve um lançamento da revisão # 12345, isso pode ser rastreado fazendo com que seja o número da compilação e se for corrigido é onde as revisões podem aumentar, pois não é uma nova funcionalidade que aumentaria as versões principais ou secundárias e o número do build deve ser lembrado caso alguém queira executá-lo novamente.

2. Identificador do servidor de integração contínua. Nesse caso, o servidor de CI pode numerar cada build executado e, portanto, o número da compilação é o que uma compilação bem-sucedida obtém e a parte da revisão não é necessária neste cenário.

Pode haver outros que eu não conheço, mas esses são os grandes que eu conheço quando se trata de números em bases de código.

Comentários

• +1 para # 1. Eu gosto de usar o revisão do controle de origem #, porque torna muito mais fácil procurar bugs relatados contra essa versão no controle de origem.
• @MasonWheeler: funciona muito bem se você estiver no SVN. Mas quando chegar ao dcvs pousar Obtém esquilo y. Isso seria algo que eu mais sinto falta sobre svn I ‘ vou adicionar.

Um número de compilação é geralmente incrementado a cada compilação, por isso é único.

Para simplificar, alguns redefinem o número da compilação sempre que os números MAJOR ou MENOR são aumentados.

A maioria dos mecanismos de integração contínua permite a geração automática de números de compilação únicos.

A revisão pode ser usada para patches do constrói. Vamos dizer que 2 equipes trabalham em um produto.

A equipe 1 é a principal equipe de desenvolvimento e produz build noturno com o seguinte esquema de versão 1.0.X.0, em que X é incrementado. Agora eles estão na versão 1.0.50.0 A equipe 2 está fazendo uma versão de vez em quando. Digamos que eles pegem a compilação da semana passada que é 1.0.43.0 e comecem a usá-la. A equipe 1 avança para 1.0.51.0 quando a equipe 2 encontra um problema em 1.0.43.0.

Agora a equipe 1 irá pegue essa compilação (43), corrija o problema e forneça à equipe 2 a compilação 1.0.43.1. A correção também pode ser propagada na compilação principal, então a mudança aparecerá em 1.0.52.0.

isso é claro e útil.

* A revisão é útil quando nem todos os envolvidos no projeto usam a mesma compilação e você precisa corrigir compilações específicas.

Deixe-me apenas dizer como o vejo e uso ….

ProgramName version major.minor.build.revision

major: Para mim é o projeto atual no qual estou trabalhando. O número não mudará até que eu comece um novo projeto com o mesmo nome de programa. Isso significa que estarei literalmente escrevendo um novo programa do mesmo gênero (exemplo: acesso v1 – acesso v-2 – acesso v-3 * tudo no mesmo programa, mas completamente reescrito).

menor: Isso significa que sou um anúncio funcionalidade de ding para o projeto publicado atualmente.Por exemplo, talvez eu tenha adicionado a capacidade de imprimir um recibo ou adicionado a capacidade de importar imagens. Basicamente, uma funcionalidade adicional que eu quero adicionar agora e não esperar pelo próximo lançamento principal para fazer isso.

build: Eu uso para indicar mudanças muito pequenas na versão major.minor publicada. Isso poderia ser uma mudança no layout, esquema de cores, etc.

revisão: Eu uso para indicar uma correção de bug no major.minor.build publicado atualmente – Há ocasiões em que não estou progredindo no projeto atual e surge um bug. Este bug precisa ser corrigido e publicado. Significa apenas que estou corrigindo o que já publiquei para funcionar corretamente. Eu também usaria isso se estivesse trabalhando em uma nova construção, uma nova adição ou iniciasse uma nova versão principal. A versão publicada obviamente precisa ser corrigida enquanto esperamos pelo próximo lançamento principal, secundário ou de compilação.

Portanto, desta forma, um projeto concluído ou parado ainda pode ser corrigido e tornado utilizável até o próximo lançamento. publicado.

Espero que isso dê a alguém uma compreensão melhor de como esse tipo de controle de versão funcionaria (ou deveria) funcionar. Para mim, é a única definição e prática que faz algum sentido real ao usar este tipo de controle de versão.

Eu só vi um número de compilação como o último número no ID de lançamento. Não tenho certeza de como você faria uma revisão para um número de compilação. Suponho que se você alterou alguns dos recursos não compilados ( ícones, script de banco de dados, etc), talvez, mas a maioria dos projetos em que trabalhei recentemente tem tudo isso sob controle de versão também, então o processo de construção os seleciona ao fazer o instalador / lançamento. Eu gosto de números de compilação com registro de data e hora, embora não exatamente como @David descreve (eu gosto de major.minor.revision.HHMM). No entanto, onde eu trabalho, usamos apenas um número sequencial que nosso servidor de compilação gera.

É o que você quiser que seja. Eu tendo a usar year.month.day.hhmm para minha revisão principal.minor.build.revision. Se estou produzindo mais de um por minuto, algo está errado. você pode apenas usar um incremento simples, ou eu vi alguns geradores elaborados para eles. O que você quer que seja. O que eles precisam fazer é fazer com que você chegue à fonte usada para criar essa saída, então tudo o que permite que você faça isso.

Nossa equipe usa o terceiro número (revisão) como o número de revisão do repositório Subversion. Usamos o quarto número (build) como o número do build do nosso servidor de integração contínua TeamCity que realmente cria o build. TeamCity cria um novo arquivo AssemblyInfo com os #s corretos nele durante o processo de build.

Como jkohlhepp, usamos a terceira parte da versão para mostrar o número da revisão na SubVersão e a quarta para mostrar o número de compilação de nosso servidor de integração contínua (Jenkins para nós). Isso nos dá vários benefícios – ter o número da versão definido por nosso servidor de CI remove uma etapa manual que poderia ser acidentalmente esquecidas; é fácil verificar se um desenvolvedor não fez um lançamento atrevido de seu PC de desenvolvimento (o que resultaria em zero); e nos permite vincular qualquer pedaço de software ao código que foi gerado de e o trabalho de CI que o construiu, apenas olhando para o número da versão – que ocasionalmente achamos muito útil.

Os dois últimos dígitos são o número total da compilação

1.01.2.1234

o número da compilação é 2.1234, no entanto, a maioria das pessoas usará apenas 1234, já que a parte 2 não muda com frequência.

Comentários

• O OP está perguntando qual é o número da compilação, não qual é o número da compilação no ID de revisão.