Data como número da versão do software

Isso é algo que você terá que dar uma olhada em alguns ângulos diferentes, já que precisa levar em conta as necessidades do usuário, bem como as necessidades do software e dos desenvolvedores.

Em geral, seus clientes não se importarão muito sobre qual será o número da versão do software, desde que eles saibam que estão executando algo mais recente (ou seja, o Produto 2012 é mais recente que o Produto 2010) e que eles sabem que está atualizado se há patches que podem ser implantados (por exemplo, Produto 2012, Atualização 10). Como tal, de um ponto de vista da marca do cliente, tenho a tendência de preferir versões com nome (por exemplo, Windows XP, Windows Vista) seguidas por um número de sequências estrito que pode ser instalado pelos usuários.

Porém, escrever um software que verifique as coisas que são fáceis para o usuário tende a tornar o código mais difícil de escrever. Assim, eu prefiro preferir o esquema simples de Major.Minor version apenas porque você pode fazer uma simples comparação de números para verificar se algo está atualizado como a seguir:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

Para colocar isso em um pouco de contexto, eu geralmente não me importo com o tamanho do número menor (ou seja, 1.1024), o que permite que o sistema acima continue funcionando com sucesso. Geralmente, os números de revisão são de interesse apenas para o desenvolvimento interno e, na verdade, ainda não os vi realmente afetando as coisas muito além de apenas dar às coisas um número adicional para acompanhar.

No entanto, os dois esquemas acima realmente não se aplicam a ambientes em que a implantação contínua está sendo usada (por exemplo, Stack Exchange), onde eu prefiro algum tipo de data seguido por um número de revisão que parece ser usado em os sites do Stack Exchange. O raciocínio para isso é que as versões vão mudar muito frequentemente no ambiente de implantação contínua e você pode ter várias versões do código subindo no mesmo dia, o que justifica o número de revisão e a data atual é tão boa quanto qualquer outra para quebrar coisas mais ainda. Teoricamente, você poderia usar apenas o número de revisão para tudo, mas o uso da data atual permite que você acompanhe internamente os principais marcos que poderiam tornar as coisas mais fáceis de serem discutidas.

O problema com o uso de uma data é que as especificações são escritas com base nos números contados e não na data de vencimento.

"This piece of functionality is due to be in release 1. The other piece of functionality is due to be in release 2."

Você não pode se referir a uma data nas especificações, já que a data de lançamento pode ser perdida.

Se você não tem um processo formal que precisa de liberações diferentes identificadas antecipadamente, o uso de datas é bom; você não precisa adicionar outro número ao mix.

Números de versão contenham datas, pois o contexto deles está vinculado a especificações.
Números de compilação provavelmente contêm datas, pois o contexto deles está vinculado a quando a construção ocorreu.

Embora essa abordagem tenha benefícios, como você descreveu, existem algumas desvantagens se você usar a data como um número de versão:

• As versões baseadas em data são simples. Com a v2.1.3, você pode ver o número da versão, o número da sub-versão e o número da sub-sub-versão. Com 20110119 você só pode ver quando foi escrito. Você poderia agrupar suas versões baseadas em datas por mês, mas ainda assim não lhe diria nada. Você pode ter vários meses lentos de conserto de bugs pequenos e depois duas semanas de codificação pesada, resultando em um grande lançamento. As datas não dizem isso, números de versão regulares fazem.

• Se você realmente precisar alterar a versão diariamente e possivelmente liberar o número, isso pode indicar que você não tem um processo de lançamento adequado, mas em vez disso, todos alteram as coisas e o promovem para os servidores de produção sempre eles querem. Em caso afirmativo, você tem um problema com o processo, e usar um esquema de número de versão diferente não resolverá o problema.

As versões costumam ser usadas para transmitir informações sobre como uma versão específica do software é diferente da anterior. Por exemplo, se você atualizar de 1.0 para 2.0 da Acme, essa é uma atualização importante, em teoria, com grandes mudanças.

Uma atualização de 1.0 para 1.1, por outro lado, é uma pequena atualização e, em teoria, carrega pequenas mudanças incrementais e correções de bugs.

Isso seria difícil de representar em um formato de data, embora você possa usar uma mistura. Por exemplo, v1.0.YYYY.MMDD

Sem repetir boas ideias de outras respostas, tenho um problema em mente que ainda não foi abordado.

Se você fizer um fork, entre uma versão mais antiga para compatibilidade com versões anteriores e uma nova versão para uma modernização incompatível, não será possível distingui-las por números de versão.

Por exemplo, o kernel do Linux foi bifurcado em torno do ano 2000 para a antiga ramificação 2.4.x, que provavelmente ainda é suportada atualmente e conta como 2.4.199, enquanto a nova versão tem 2.6 por muitos, muitos anos e é 2.6.32 para sistemas mais antigos, mas 3.2 para os mais novos kernels.

Se você tem documentação sobre seus lançamentos, você vai dobrar as informações e informar as pessoas, que a versão 20120109 chegou em 2012 em 01/09. Mh. Mas o que, se houver uma detecção de bug no último momento, e uma liberação está atrasada por uma semana, mas a documentação, onde o nome é mencionado, já está pronta, talvez impressa, informações de imprensa estão fora e assim por diante. Agora você tem uma discrepância que é problemática, se a versão 20120109 chegou em 2012/01/13.

No SQL, a questão de se os IDs devem conter informações semânticas tem sido freqüentemente discutida, e o resultado é sempre: evitá-lo como o inferno! Você está criando uma dependência desnecessária. Não pode ser benéfico.

Existem muitos pacotes de software que realmente usam a data como uma versão. Ubuntu vem à mente, onde sua versão é YY.MM. E os números de compilação para produtos Microsoft Office também são uma codificação do data de construção. Jeff Atwood escreveu uma postagem no blog Coding Horror sobre a numeração de versões incluindo esta recomendação:

Whenever possible, use simple dates instead of version numbers, particularly in the public names of products. And if you absolutely, positively must use version numbers internally, make them dates anyway: be sure to encode the date of the build somewhere in your version number.

Na minha opinião, não importa, contanto que você seja consistente e seja capaz de ir de um número de versão de compilação (seja lá o que for) e lembre-se de todos os artefatos que foram criados no seu sistema de controle de versão. Os usuários normalmente não se importam com as informações da versão, mas com a funcionalidade fornecida pelo sistema. As informações sobre controle de versão são apenas de valor real para os desenvolvedores.

Use o versionamento semântico - assim, você tem uma ideia do tipo de alterações feitas entre as versões sem precisar inspecionar o próprio código: link

Usar números de versão é uma maneira de mostrar como GRANDE a mudança é

Por exemplo, 2.4.3 pode significar que a versão 2 é a principal mudança em todo o sistema. .4 é uma atualização secundária. e a última .3 é uma pequena correção de bug para essa versão. Dessa forma, é facilmente reconhecível o quanto mudou entre cada versão.

Algumas boas respostas aqui já, mas gostaria de destacar um caso em que usar datas faz todo o sentido: pequenas bibliotecas ou trechos de código onde o código provavelmente será atualizado com frequência, mas em pequenos pedaços sem uma única versão que diferencie drasticamente para o anterior.

Em outras palavras, estou falando de situações em que não há um "número de versão" real, mas basicamente uma espécie de despejo de repositório quase diário.

Quando me deparo com esse tipo de coisa, geralmente saúdo a escolha, pois é mais útil para mim saber que estou usando um script / lib relativamente atual, em vez de uma versão específica.

Datas como um número de versão são boas para marketing. Se as pessoas estiverem usando o "Windows NT 5.0", elas podem não perceber que é obsoleto. Mas se as pessoas ainda estiverem usando o "Windows 2000", elas saberão instantaneamente que é um sistema operacional de 12 anos e serão incentivadas a fazer upgrade.

No entanto, dificulta a distinção entre atualizações "principais" e "menores".

Eu não gosto dessa ideia, por motivos já descritos por outros. Basta usar o esquema major.minor.bugfix - há uma razão pela qual a maioria das pessoas faz dessa maneira.

Mas faça o que fizer: escolha um esquema de nomes de versões e atenha-se a ele . Não faça como o Windows, onde eles mudam o esquema a cada lançamento. E não faça como o Android, onde cada versão tem um número de versão da API (8), um número de versão que se destina ao marketing (2.2) e um nome estúpido (Froyo).

Problema ao usar datas como números de versão

As respostas aqui são boas, mas não vi ninguém abordar essa preocupação ao usar datas: o usuário não pode determinar com que frequência as modificações foram feitas.

O que estou tentando dizer é que posso dizer que o Windows 3.1 e o Windows 7 estão muito distantes ... e talvez sejam incompatíveis. O Windows 95 e o Windows 2000 não me dizem nada mais do que o ano em que o produto foi introduzido.

Por exemplo, com o Python, eu sei que a versão 2.7.2 evoluiu de 2.4.6. Se eu olhar mais, vejo que a versão 2.4.6 foi lançada em 19 de dezembro de 2008; e que a versão 2.7.2 foi lançada em 11 de junho de 2011. A partir disso, posso formar uma opinião sobre a estabilidade (ou seja, a frequência de lançamento) de um produto.

Se, em vez disso, o Python usasse datas de lançamento, não sei como esses produtos podem estar conectados. Mais confusão resultaria, porque o Python 3.1.4 também foi lançado em 11 de junho de 2011 (o mesmo que o Python 2.7.2).

Em suma, não acho que, por si só, o versionamento de datas seja valioso.

Data como versão

Se o seu produto não for vendido, basta usar a data e, provavelmente, é útil. Se você vende e atualiza para os clientes, eles querem comprar um modelo com um conjunto específico de recursos. É muito mais fácil vendê-los em uma atualização, se este modelo tem um nome claro, não importa realmente o que é, mas por exemplo, ninguém realmente compra o 20 de janeiro de 2012 Ford Car eles querem o modelo Kia qualquer. O mesmo acontece com o software. Dar um nome e uma versão do modelo físico significa que ele possui recursos diferentes dos mais antigos. Para mim, apenas uma data não faz isso, diz que eu fiz então, não pode ter novos recursos.

Esquema que usamos

Eu não reivindiquei que nosso sistema cria uma marca clara como acima. Nós agora usamos um esquema de quatro partes. Um número de versão, estado, a data e uma soma de verificação.

1200_GLD_120120_F0D1

Isso pode ser um pouco exagerado, mas permite que tenhamos várias versões do build para a versão 1200 que nossos engenheiros podem usar e nós as diferenciamos por data. O estado informa às pessoas se é uma versão de teste interna, compilação de patch do cliente ou release gold. A checksum é nova, permite que um engenheiro ou cliente verifique se eles realmente baixaram o correto da nossa distribuição.

Então, podemos ter uma sequência de

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Normalmente, nos referimos aos números das versões principais para o cliente, ou seja, "12", mas um cliente receberá a última versão em ouro de 12, ou seja, 1200_GLD_120120_F0D1, a menos que precise da Correção.

Digamos que alguns clientes usem a versão dois do seu produto e alguns tenham atualizado para a versão três, e essa atualização não é uma decisão tomada com leviandade.

Digamos que a última versão da versão dois é 2.3.2 e a versão três é a 3.0.3. Agora você encontra uma vulnerabilidade que absolutamente precisa ser corrigida, então você libera 2.3.3 e 3.0.4 no mesmo dia. Você pode ver como a data de lançamento é totalmente irrelevante? Você pode ter parado de trabalhar na versão dois em 2013 e só liberou algumas correções de bugs essenciais desde então. A data é irrelevante em comparação com o número da versão.

Eu acho que funciona muito bem. Eu uso para alguns softwares internos (yyyy.mm.dd) e para alguns softwares de código aberto que eu lancei.

Pode não funcionar em todos os casos.

Tecnicamente Não é possível usar a data para o número da versão, mas pode mostrar o número da data para o cliente. Por exemplo, macOS 16.7.23 --- significa que: 23/7/2016

Eu acho que a tecnologia não é o problema, o problema é como se sente? Se o número de data de uso que poderia tornar o software vivo, vivendo, assim como um homem que número de aniversário. Todo ano que estamos crescendo, O mesmo que software é continuar crescendo.

O número do prédio parece com a máquina, a máquina, sem vida, sem vida.