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

Eu nunca vi escrito dessa forma. Onde eu trabalho, estamos usando o formato MAJOR.MINOR.REVISION.BUILDNUMBER, onde MAJOR é uma versão principal (geralmente muitos recursos novos ou alterações na interface do usuário ou sistema operacional subjacente), MINOR é uma versão secundária (talvez alguns novos recursos) em uma versão anterior, a REVISION é geralmente uma correção para uma versão menor anterior (sem novas funcionalidades), e BUILDNUMBER é incrementado para cada compilação mais recente de uma revisão.

Por exemplo, uma revisão pode ser liberada para o controle de qualidade (controle de qualidade) e eles retornam com um problema que requer uma alteração. O bug seria corrigido e liberado de volta para o controle de qualidade com o mesmo número de REVISÃO, mas um BUILDNUMBER incrementado.

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

major.minor[.build[.revision]]

The components are used by convention as follows:

Major: Assemblies with the same name but different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.

Minor: If the name and major version number on two assemblies are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.

Build: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.

Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.

link

Toda a confusão decorre da diferente semântica que a MS usa para "Build number" e especialmente "Revision". Os termos significam apenas coisas diferentes.

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

Incrementar REVISÃO, no entanto, indica um novo ramo de lançamento permanente, é por isso que o colocamos antes do BUILD. A desvantagem dessa abordagem é que podemos obter a seguinte sequência de eventos:

• número de confirmação 4711: Alice adicionou o recurso A
• CI produz build 1.2.3.100
• número de confirmação 4712: recurso modificado por Bob B
• número de confirmação 4713: recurso fixo de Alice A (o "hotfix")
• CI produz build 1.2.3.101

Comovocêpodever,ohotfixnãoéaúnicaalteraçãocontidanapróximacompilação,eamodificaçãodeBobtambémfazpartedessacompilação.Sevocêquiserestabilizararamificaçãoatual,vocêpodeterproblemas,poisvocênuncapodetercertezaseBobacaboudeadicionaralgunsbugs.

OMSusaosdoistermosdemaneiradiferente.OnúmeroBUILDnãoéincrementadoautomaticamente,emvezdisso,podeserconsideradocomoumaespéciederamificaçãoderelease,paracongelarocódigousadoparaumaversãoespecíficadocódigo.AREVISIONindicaalterações"quentes" adicionais aplicadas a essa ramificação BUILD. A sequência seria, portanto, a seguinte:

• número de confirmação 4711: Alice adicionou o recurso A ao tronco / mestre
• Carl cria ramificação de construção 1.2.100
• CI produz compilação 1.2.100.0
• número de confirmação 4712: Bob modificou o recurso B no tronco / mestre
• número de confirmação 4713: o recurso fixo A da Alice na ramificação 1.2.100
• o CI produz a compilação 1.2.100.1

OtermoREVISÃOpodesereferira

• umarevisãodoproduto(éassimqueamaioriadaspessoasoutiliza)
• umarevisãodeumadeterminadaconstruçãodiária(éissoqueaMSfaz)

AprincipaldiferençaentreosdoisprocessosésevocêdesejaounãoacapacidadedeaplicarhotfixesàsconstruçõesdeCIe,assim,emquepontodoprocessoaramificaçãoéfeita.Esseaspectotorna-seimportantequandovocêdesejaescolherumadeterminadaversãoaqualquermomentoapóstodosostestesteremsidobem-sucedidosepromoverexatamenteessaversãoparaapróximaversãooficialdeseuproduto.

Nonossocaso,aferramentaCIcriaumatagderepositório,portanto,sempretemosasinformaçõesnecessáriasprontasparausar,quandonecessário.ComoSVN,torna-seaindamaissimples,porquetagsebranchessãoimplementadosexatamentedamesmamaneira-umatagnadamaisédoqueumaramificaçãolocalizadaem/tags.

Vejatambém

Naseçãodeperguntasfrequentes,em Estratégia de ramificação do TFS :

In what branch should I fix the P1 (hotfix) ticket?

• The P1 should be fixed in the branch that is closest to the code base running in Production. In this case the P1 should be fixed in the Prod branch. By applying the fix in any other branch and rolling out the changes to production you risk releasing semi-finished or untested code from the subsequent iterations.

• Now you may argue if it is safe to work directly against the Prod branch, think again, a P1 that requires immediate attention should not be a fundamental problem in the system. In case it is a fundamental problem it should be added to the Product backlog as it may require further analysis and discussion with the customer.

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

Há pelo menos algumas coisas diferentes que eu poderia imaginar o número da compilação referenciando:

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 por ter sido o número de compilação e se ele for corrigido é onde as revisões podem subir, pois não é uma nova funcionalidade que aumentaria as versões principais ou secundárias e o número da compilação deve ser lembrado caso alguém queira executar essa compilação novamente.

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

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

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

Por questões de simplicidade, alguns redefinem o número de compilação sempre que os números MAJOR ou MINOR são colididos.

A maioria dos mecanismos de integração contínua permite números de compilação exclusivos gerados automaticamente.

A revisão pode ser usada para patches das compilações. Vamos dizer que 2 equipes trabalham em um produto.

A equipe 1 é a principal equipe de desenvolvimento e produz a criação noturna com o seguinte esquema de versão 1.0.X.0, em que X é incrementado. Agora eles estão no build 1.0.50.0 A equipe 2 está fazendo uma compilação de tempos em tempos. Vamos dizer que eles pegaram a compilação da semana passada que é 1.0.43.0 e começaram 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, o time 1 levará esse build (43), consertará o problema e fornecerá ao time 2 o build 1.0.43.1. A correção também pode ser propagada na construção principal, portanto, a alteração aparecerá em 1.0.52.0.

Espero que isso seja 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 dizer como vejo e uso ....

Versão do nome do programa major.minor.build.revision

major: Para mim é o atual projeto em que estou trabalhando. O número não será alterado até que eu inicie um novo projeto com o mesmo nome de programa. Isso significa que eu irei literalmente escrever um novo programa do mesmo gênero (exemplo: acesso v1 - acesso v-2 - acesso v-3 * todo o mesmo programa, mas completamente reescrito).

menor: Isso significa que estou adicionando funcionalidade ao atual projeto publicado. Por exemplo, talvez eu tenha adicionado a capacidade de imprimir um recibo ou adicionar a capacidade de importar imagens. Basicamente, a funcionalidade adicional que quero adicionar agora e não esperar pela próxima versão principal.

build: Isso é usado para indicar alterações muito pequenas na versão major.minor publicada. Isso pode ser uma mudança no layout, esquema de cores, etc.

revisão: Isso 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 compilação, uma nova adição ou iniciando uma nova versão principal. A versão publicada obviamente precisa ser corrigida enquanto aguardamos o próximo lançamento principal, secundário ou de compilação.

Dessa forma, um projeto finalizado ou parado pode ser corrigido e tornado utilizável até a próxima publicação ser publicada.

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

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ê elaboraria uma revisão para um número de compilação. Eu suponho que se você alterou alguns dos recursos não construídos (ícones, script de banco de dados, etc), talvez, mas a maioria dos projetos que eu trabalhei recentemente tem tudo isso sob controle de versão também, então o processo de construção os pega quando fazendo o instalador / release. Eu gosto de números de compilação com registro de data e hora, embora não exatamente como descreve o @David (eu gosto de major.minor.revision.HHMM). No entanto, onde eu trabalho, usamos apenas um número seqüencial gerado pelo nosso servidor de compilação.

Como o jkohlhepp, usamos a terceira parte da versão para mostrar o número da revisão em SubVersion e a quarta para mostrar o número da compilação do 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 pelo nosso servidor de CI remove uma etapa manual que, caso contrário, poderia ser perdida acidentalmente; é fácil verificar se um desenvolvedor não fez uma versão atrevida do PC de desenvolvimento (o que resultaria em zero nesses números); e permite-nos ligar qualquer parte do software ao código que foi gerado a partir de e o trabalho de CI que o construiu, apenas olhando para o número da versão - que ocasionalmente achamos muito útil.

É o que você quer que seja. Eu costumo usar year.month.day.hhmm para minha major.minor.build.revision. Se estou produzindo mais de um por minuto, algo está errado. você pode simplesmente usar um incremento simples, ou eu já 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 o que quer que o permita fazer isso.

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

1.01.2.1234

o número de compilação é 2.1234, mas a maioria das pessoas usa apenas 1234, já que a parte 2 não muda com frequência.

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 de compilação do nosso servidor de integração contínua TeamCity, que na verdade cria a compilação. O TeamCity cria um novo arquivo AssemblyInfo com os #s corretos durante o processo de compilação.