Quando você altera o número da sua versão principal / secundária / de correção?

37

Você altera seus números de versão principais / secundários / de correção antes de liberar ou logo depois?

Exemplo: Você acabou de lançar 1.0.0 para o mundo (huzzah!). Mas espere, não comemore demais. 1.1.0 está saindo em seis semanas! Então você conserta um bug e faz uma nova compilação. Como se chama essa construção? 1.1.0.0 ou 1.0.0.xxxy (onde xxxy é o número de compilação de 1.0.0 incrementado)?

Tenha em mente que você pode ter 100 recursos e bugs para entrar no 1.1.0. Por isso, pode ser bom chamá-lo de 1.0.0.xxxy, porque você não está nem perto de 1.1.0. Mas por outro lado, outro dev pode estar trabalhando em 2.0.0, caso em que sua compilação pode ser melhor chamada 1.1.0.0 e seu 2.0.0.0 em vez de 1.0.0.xxxy e 1.0.0.xxxz, respectivamente. / p>     

por dave4351 26.09.2012 / 02:23
fonte

7 respostas

23

Depois de lançar seu software, o número da versão deve ser incrementado imediatamente.

Por quê?

Vamos supor que você esteja seguindo um esquema como Semântica de versões e tenha um número de compilação na versão. Então você pode ter [Major]. [Menor]. [Patch]. [Build]. Eu vou chamar o [Major]. [Menor]. [Patch] parte a versão.

Você estará criando várias compilações durante o desenvolvimento. Cada build é um instantâneo de desenvolvimento do seu próximo lançamento. Faz sentido usar a mesma versão para suas construções de desenvolvimento e lançamento. A versão indica em qual versão você está trabalhando para .

Se você estiver se preparando para o lançamento e o software passar em todos os testes, não será necessário recriar e testar novamente o software só porque você precisou atualizar a versão. Quando você finalmente faz um lançamento, você está afirmando que "build 1.1.0.23" será doravante referido como "versão 1.1.0".

O modelo de incremento após lançamento também faz sentido para ramificação. Suponha que você tenha uma ramificação de desenvolvimento de linha principal e crie ramificações de manutenção para liberações. No momento em que você cria sua ramificação de lançamento, sua ramificação de desenvolvimento não está mais vinculada ao número de versão dessa versão. O ramo de desenvolvimento contém código que faz parte do próximo lançamento, então a versão deve refletir isso.

    
por 26.09.2012 / 14:25
fonte
4

Eu geralmente tento usar SemVer para números de versão internos. É bom poder saber algo sobre uma versão com base na semântica do seu número de versão.

Durante o desenvolvimento, eu tento alterar os números de versão imediatamente (se possível) . Às vezes é difícil saber se a mudança será ou não uma mudança (o que influenciará o número da minha versão), então nada é "imutável".

Para abordar seu exemplo específico:

  • Durante o desenvolvimento, as versões de pré-lançamento seriam 1.0.1-alpha.1, 1.0.1-alpha.2, etc.
  • A versão final do bug-fix seria a versão 1.0.1.

Dito isto, os números de versão do produto 'voltados para o público' são muitas vezes definidos pelo marketing e são completamente diferentes. Isso está fora do meu controle, então não se preocupe com isso.

    
por 26.09.2012 / 03:25
fonte
3

Em projetos / organizações maiores, os números das versões principais e secundárias são controlados pelos departamentos de marketing e geralmente são incrementados por motivos de marketing. Na minha organização, os grupos visam liberar um lançamento maior e um menor a cada ano. A expectativa é que as principais versões contenham novas funcionalidades significativas e que haja compatibilidade binária entre as APIs para todas as versões com o mesmo número de versão principal. No entanto, o marketing pode optar por rebaixar uma alteração de versão principal para menor, porque os recursos prometidos não são entregues ou vice-versa, por exemplo, para aumentar a concorrência de rãs.

Os números maiores e menores (c e d em a.b.c.d) são geralmente controlados pelo desenvolvimento. c é o número da compilação e d é usado para correções em uma versão ou versão específica de c.

No seu caso, quando você altera os números das versões principais e secundárias, é menos relevante do que garantir que os números maiores e menores da versão sejam precisos. Na minha organização, alteramos os números de compilação principais e secundários como parte do processo de ramificação no controle de origem. O ramo principal geralmente contém a versão mais recente, mas o marketing pode não ter decidido qual o número da versão que o lançamento terá ainda.

    
por 26.09.2012 / 03:00
fonte
3

Let's assume A.B.C.D in the answers. When do you increase each of the components?

É basicamente determinado pela política da sua empresa. A política da nossa empresa é:

  • A - alterações significativas (> 25%) adições na funcionalidade ou interface.
  • B - pequenas alterações ou adições na funcionalidade ou interface.
  • C - pequenas alterações que quebrar a interface.
  • D - correções para um construir que não mudam o interface.
por 26.09.2012 / 04:41
fonte
2

Tentamos seguir o exemplo do Eclipse . Ele explica melhor do que eu, mas efetivamente funciona da seguinte maneira:

Ao liberar 1.0.0.0, o número da versão para o qual você muda depende do tipo de alteração que você está fazendo.

  • Uma versão que não afeta a API, considere uma correção de bug nos bastidores que faz a API atual funcionar da maneira esperada, é lançada em 1.0.1
  • Uma versão que adiciona à API, mas não altera a API existente, você pode ter adicionado um novo recurso que não torna os clientes atuais incomparáveis com a nova versão. Isso pode incluir qualquer número das correções acima também.
  • Um release quebra a API atual, removendo algo, alterando algo da maneira que quebra a comparabilidade com os clientes atuais. Isso pode ter qualquer um dos ajustes acima também.

Quanto a como usar a 4ª seção no número da versão, usamos isso para diferenciar as diferentes construções no Nuget (a solução de gerenciamento de pacotes que usamos para .net). Isso nos permite evitar ter que limpar os caches toda vez que precisarmos atualizar nosso software não lançado.

    
por 26.09.2012 / 02:29
fonte
1

Não há próxima compilação. Nesse ramo.

Versão idealizada do nosso esquema.

A identificação da versão em qualquer filial é PRETTY_BRANCH_NAME-build e PRETTY_BRANCH_NAME é corrigida na criação da filial.

Nosso esquema de ramificação (*) é o seguinte:

Filiais de nível superior, o PRETTY_BRANCH_NAME de cada é um nome de código, falando de número de versão nesse nível não tem sentido, pode haver um esquema planejado, mas ele será alterado antes do lançamento.

  • uma ramificação TNG ( a próxima geração ) onde o desenvolvimento a longo prazo é feito. Muitas vezes nem temos isso e nunca sub-ramificações.

  • uma ramificação TCG ( a geração atual ) onde o desenvolvimento atual é feito. PRETTY_BRANCH_NAME é um nome de código.

  • uma ramificação TPG ( a geração anterior ). Muitas vezes não há mais desenvolvimento aqui, mas pode haver atividade nas sub-ramificações.

Um sub-ramo é feito de uma ramificação de nível superior (de TCG, na presença de migração lenta de TPG) quando beta para um grande lançamento inicial. O PRETTY_BRANCH_NAME é algo como "1.3.X" (X é a letra, não o dígito, significa que pretendemos entregar 1.3 versões a partir daqui), o feedback da versão beta é token em conta aqui enquanto o trabalho para o próximo grande lançamento é feito em o ramo do TCG.

Idealmente, o lançamento deve ser instantâneo nesse ramo, mas sabemos que não somos perfeitos e geralmente precisamos fazer alterações de última hora, enquanto outros ainda podem continuar trabalhando para o próximo lançamento menor. Assim subsubbranches são feitas para a estabilização final com nomes bonitos sendo o número da versão oficial (na época até mesmo o marketing não vai querer mudá-lo) como "1.3", "1.3.1" fora da ramificação "1.3.X", a última compilação de cada um é o lançamento.

Se tivéssemos um quarto nível, os nomes das sub-ramificações teriam sido "1.3.0.X", dos quais teríamos sub-3 ramificações "1.3.0.0" "1.3.0.1".

(*) no nível de lançamento. Pode haver sub-ramificações de projeto em cada uma delas.

    
por 26.09.2012 / 09:04
fonte
1

Se você está vendendo software, você terá um novo lançamento cada vez que as vendas / marketing precisarem ganhar um bônus maior: -)

Se você tiver algum controle, então: -

Principais versões quando: -

  • Existe alguma incompatibilidade com a versão anterior que requer conversão, etc. Pense no Pyhton 2 ... no Python 3 ...

  • O é um pedaço inteiro de novas funcionalidades

    Realizações menores para qualquer pequeno cange em funcionalidade, lançamento de patch para correções de bugs.

por 14.10.2014 / 04:24
fonte

Tags