Quando você altera o número da versão principal / secundária / do patch?

Possível duplicado:
Que "convenção de nomenclatura de versão" você usa?

Você altera seus números de versão principais / secundários / patches imediatamente antes do lançamento ou logo após?

Exemplo: Você acabou de lançar a 1.0.0 para o mundo (huzzah!). Mas espere, não comemore demais. 1.1.0 será lançado em seis semanas! Então você corrige um bug e faz uma nova compilação. Como é chamado esse build? 1.1.0.0 ou 1.0.0.xxxy (onde xxxy é o número de compilação da 1.0.0 incrementado)?

Lembre-se de que você pode ter 100 recursos e bugs para entrar no 1.1.0. Portanto, 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 desenvolvedor pode estar trabalhando no 2.0.0. Nesse caso, sua compilação pode ser melhor denominada 1.1.0.0 e 2.0.0.0 em vez de 1.0.0.xxxy e 1.0.0.xxxz, respectivamente.

Após o lançamento do software, o número da versão deve ser incrementado imediatamente.

Por quê?

Vamos supor que você esteja seguindo um esquema como o Semantic Versioning e que tenha um número de compilação na versão. Então você pode ter [Major]. [Menor]. [Patch]. [Build]. Vou chamar a parte [Major]. [Menor]. [Patch] da versão.

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

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

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

Eu geralmente tento usar o SemVer para números de versão internos. É bom saber algo sobre um lançamento com base na semântica do número da versão.

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

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 da correção de bug seria a versão 1.0.1.

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

Vamos assumir o ABCD nas respostas. Quando você aumenta cada um dos componentes?

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

• A - Alterações significativas (> 25%) ou acréscimos na funcionalidade ou na interface.
• B - pequenas alterações ou acréscimos na funcionalidade ou na interface.
• C - pequenas alterações que quebram a interface.
• D - corrige uma compilação que não altera a interface.

Em projetos / organizações maiores, os números de versão principais e secundários são controlados pelos departamentos de marketing e geralmente são incrementados por razões de marketing. Na minha organização, os grupos pretendem lançar uma versão principal e uma versão secundária a cada ano. A expectativa é que os principais lançamentos contenham novas funcionalidades significativas e haja compatibilidade binária entre APIs para todos os lançamentos com o mesmo número de versão principal. No entanto, o marketing pode optar por fazer o downgrade de uma alteração de versão principal para menor porque os recursos prometidos não são entregues ou vice-versa, por exemplo.

Os números principais e secundários de compilação (c e d em abcd) são geralmente controlados pelo desenvolvimento. c é o número da compilação ed é usado para correções em uma liberação ou versão específica de c.

No seu caso, quando você altera os números de versão principais e secundários, é menos relevante do que garantir que os números de compilação principais e secundários sejam precisos. Na minha organização, alteramos os números principais e secundários de compilação 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 número de versão o release ainda terá.

Tentamos seguir o exemplo do Eclipse . Ele explica melhor do que eu, mas efetivamente para nós funciona assim:

Quando você libera a 1.0.0.0, o número da versão para a qual você altera depende do tipo de alteração que está sendo feita.

• Uma versão que não afeta a API, considere uma correção de bug nos bastidores que faz com que a API atual funcione da maneira esperada, é lançada na 1.0.1
• Uma versão que é adicionada à 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.
• Uma versão quebra a API atual, removendo algo, alterando algo da maneira que quebra a comparabilidade com os clientes atuais. Isso também pode ter várias das correções acima.

Quanto a como usar a 4ª seção no número da versão, usamos isso para diferenciar diferentes compilaçõ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 precisamos atualizar nosso software não lançado.

Não há construção seguinte. 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:

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

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

• um ramo do TCG ( a geração atual ) em que é feito o desenvolvimento atual. PRETTY_BRANCH_NAME é um nome de código.

• um ramo de TPG ( a geração anterior ). Muitas vezes, não há mais desenvolvimento aqui, mas pode haver atividade nas sub-filiais.

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

Idealmente, o release deve ser instantâneo nesse ramo, mas sabemos que não somos perfeitos e geralmente precisamos fazer alterações de última hora, permitindo que outras pessoas continuem trabalhando para o próximo release menor. Assim, as sub-filiais são feitas para a estabilização final, com nomes bonitos sendo o número da versão oficial (naquele momento, mesmo o marketing não vai querer alterá-lo) como "1.3", "1.3.1" fora do ramo "1.3.X", a última compilação em cada um é o lançamento.

Se tivéssemos um quarto nível, os nomes das sub-filiais seriam "1.3.0.X", dos quais teríamos sub-3 filiais "1.3.0.0" "1.3.0.1".

(*) No nível do release. Pode haver sub-filiais do projeto em cada uma delas.

Se você estiver vendendo software, terá uma nova versão principal sempre que as vendas / marketing precisarem ganhar um bônus maior :-).

Se você tiver algum controle, então:

1. Principais lançamentos quando:

   • Há alguma incompatibilidade com a versão anterior que requer conversão, etc., como do Python 2 para o Python 3.

   • Há um monte de novas funcionalidades.

2. Versões menores para pequenas alterações na funcionalidade.

3. Lançamento de patch para correções de bugs.