Prática recomendada: versão do software [fechada]

Existe alguma diretriz ou prática recomendada padrão para a versão de um software que você desenvolve em seu tempo livre por diversão, mas mesmo assim será usado por algumas pessoas? Eu acho que é necessário fazer a versão desse software para que você saiba sobre a versão 1 (por exemplo, para correção de bugs, suporte etc.).

Mas por onde começo a versão? 0.0.0? ou 0,0? E então como eu incremento os números? principal release.minor mudança? e nenhum comprometimento com um sistema de controle de versão deveria ser outra versão? ou isso é apenas para versões usadas de maneira produtiva?

Você deve começar com a versão 1, a menos que saiba que a primeira versão que você "libera" está incompleta de alguma forma.

Quanto a como você incrementa as versões, isso depende de você, mas use a numeração de compilação maior e menor como um guia.

Não é necessário ter todas as versões comprometidas no controle de origem como outra versão - em breve você terá um número de versão muito grande. Você só precisa incrementar o número da versão (de alguma forma) ao liberar uma nova versão para o mundo externo.

Portanto, se você fizer uma alteração importante, mude da versão 1.0.0.0 para a versão 2.0.0.0 (você mudou do WinForms para o WPF, por exemplo). Se você fizer uma alteração menor, passe de 1.0.0.0 para 1.1.0.0 (você adicionou suporte para arquivos png). Se você fizer uma pequena alteração, passe de 1.0.0.0 para 1.0.1.0 (você corrigiu alguns bugs).

Se você realmente deseja obter detalhes, use o número final como o número da compilação que aumentaria para cada check-in / commit (mas acho que isso está indo longe demais).

Eu usaria x.y.ztipo de versionamento

x- versão principal - versão
ysecundária
z- número da compilação

Basicamente, sigo esse padrão:

• começar a partir de 0.1.0

• quando estiver pronto, ramifico o código no repositório de origem, identifico a 0.1.0 e crio a ramificação 0.1.0, o cabeçalho / tronco torna-se 0.2.0-snapshot ou algo semelhante

• Eu adiciono novos recursos apenas ao tronco, mas o backport corrige o ramo e, com o tempo, libero-o 0.1.1, 0.1.2, ...

• Declaro a versão 1.0.0 quando o produto é considerado completo do recurso e não apresenta grandes deficiências

• a partir de então - todos poderão decidir quando incrementar a versão principal ...

Eu uso esta regra para meus aplicativos:

xyz

Onde:

• x = número da versão principal, 1- ~.
• y = número do recurso, 0-9. Aumente esse número se a alteração contiver novos recursos com ou sem correção de bugs.
• z = número do hotfix, 0- ~. Aumente esse número se a alteração contiver apenas correções de bugs.

Exemplo:

• Para o novo aplicativo, o número da versão começa com 1.0.0.
• Se a nova versão contiver apenas correções, aumente o número do hotfix para que o número da versão seja 1.0.1.
• Se a nova versão contiver novos recursos com ou sem correções, aumente o número do recurso e redefina o número do hotfix para zero, para que o número da versão seja 1.1.0. Se o número do recurso atingir 9, aumente o número da versão principal e redefina o número do recurso e do hotfix para zero (2.0.0, etc.)

Usamos abcd onde

• a - principal (incrementado na entrega ao cliente)
• b - menor (incrementado na entrega ao cliente)
• c - revisão (incrementada em releases internos)
• d - construção (incrementada pelo controle de cruzeiro)

Outro exemplo para a A.B.Cabordagem é o Eclipse Bundle Versioning . Os pacotes do Eclipse têm um quarto segmento:

No Eclipse, os números de versão são compostos por quatro (4) segmentos: 3 números inteiros e uma cadeia de caracteres, respectivamente major.minor.service.qualifier. Cada segmento captura uma intenção diferente:

• o segmento principal indica quebra na API
• o segmento menor indica alterações "externamente visíveis"
• o segmento de serviço indica correções de erros e a mudança do fluxo de desenvolvimento
• o segmento qualificador indica uma construção específica

Há também o sistema de controle de versão data , por exemplo: YYYY.MM, YY.MM,YYYYMMDD

É bastante informativo, porque um primeiro olhar dá uma impressão sobre a data de lançamento. Mas prefiro o esquema xyz, porque sempre quero saber o ponto exato de um produto em seu ciclo de vida (Major.minor.release)

A resposta básica é "Depende".

Qual é o seu objetivo no versionamento? Muitas pessoas usam version.revision.build e apenas anunciam version.revision para o mundo, pois é uma versão de lançamento, e não uma versão de desenvolvimento. Se você usar a 'versão' de check-in, descobrirá rapidamente que os números de sua versão se tornam grandes.

Se você está planejando seu projeto, eu aumentaria a revisão de lançamentos com pequenas alterações e a versão de incrementos para lançamentos com grandes mudanças, correções de bugs ou funcionalidade / recursos. Se você estiver oferecendo versões do tipo beta ou noturno, estenda o controle de versão para incluir a versão e o incremento a cada versão.

Ainda assim, no final do dia, cabe a você e tem que fazer sentido para você.

Como Mahesh diz: eu usaria o tipo de versão xyz

x - versão principal y - versão secundária z - número da compilação

convém adicionar uma data e hora, talvez em vez de z.

Você incrementa a versão secundária quando tem outra versão. A versão principal provavelmente permanecerá 0 ou 1; você a altera quando realmente faz grandes alterações (geralmente quando o software está em um ponto em que não é compatível com versões anteriores das versões anteriores ou você mudou toda a estrutura)

Você sabe que sempre pode verificar o que os outros estão fazendo. Softwares de código aberto tendem a permitir o acesso a seus repositórios. Por exemplo, você pode apontar seu navegador SVN para http://svn.doctrine-project.org e dar uma olhada no sistema de versão usado por um projeto real.

Números de versão, tags, está tudo lá.

Seguimos a abordagem abc como:

aumento 'a' se ocorrerem algumas mudanças importantes no aplicativo. Como atualizamos o aplicativo .NET 1.1 para o .NET 3.5

aumento 'b' se houver algumas alterações menores, como qualquer novo CR ou aprimoramento.

aumento 'c' se houver alguma correção de defeitos no código.

Começo a versão no segmento mais baixo (sem hotfix). Não limito esse segmento a 10. A menos que você esteja acompanhando as compilações, basta decidir quando deseja aplicar um incremento. Se você tiver uma fase de controle de qualidade, pode ser onde você aplica um incremento ao segmento mais baixo e, em seguida, o próximo segmento quando passa no controle de qualidade e é liberado. Deixe o segmento mais alto para alterações de comportamento / interface do usuário principais.

Se você é como eu, fará dele um híbrido dos métodos, a fim de acompanhar o ritmo da progressão do seu software.

Eu acho que o padrão mais aceito abc ou abcd, especialmente se você tiver controle de qualidade / conformidade no mix. Eu tive tanta confusão em torno da data sendo uma parte regular das versões que eu desisti para o mainstream.

Eu não rastreio compilações, então eu gosto de usar o padrão abc, a menos que um hotfix esteja envolvido. Quando preciso aplicar um hotfix, aplico o parâmetro d como uma data com hora. Adotei o parâmetro time como d, porque sempre há o potencial de vários em um dia em que as coisas realmente explodem na produção. Só aplico o segmento d (AAAAMMDDHHNN) quando estou divergindo para uma correção de produção.

Pessoalmente, não me oponho a um esquema de software do va.b revc, em que c é AAAAMMDDHHMM ou AAAAMMDD.

Tudo o que disse. Se você puder pegar uma ferramenta para configurá-la e executá-la, evitará a dor de cabeça, tendo que organizar a faceta de opinião do controle de versão e você pode simplesmente dizer "use a ferramenta" ... porque todos no processo de desenvolvimento geralmente são tão compatíveis .