O que usar como uma versão inicial? [fechadas]

Normalmente começo meus projetos com a versão 1.0.0. Assim que tenho algumas coisas juntas, libero-o como 1.0.0 e continuo com 1.1.0.

No entanto, isso leva ao uso, mas não exatamente, da versão completa 1.0.0 da maioria das coisas que escrevo. Depois, adiciono recursos e chego a uma versão decente em torno da 1.6.0. Muitos projetos começam com a versão 0.1.0, que será tão utilizável quanto a minha 1.0.0.

O que você sugeriria fazer? Comece com 1.0.0 ou 0.1.0?

O último número é para lançamentos de correções apenas a propósito. Você pode pensar no meu 1.0.0 como 1.0 e 0.1.0 como 0.1 é mais fácil para você.

Meu controle de versão é orientado pela instalação. Quero que ele substitua versões mais antigas, por isso continuo aumentando em saltos que fazem sentido para mim.

Às vezes, no entanto, o controle de versão é orientado pelo cliente, especialmente se você estiver lançando código para o público.

Se a decisão for sua, faça o que for melhor para você. Eu tive alguns problemas com as versões anteriores à 1.0, então começo com isso.

O padrão Semantic Versioning 2.0.0 diz:

A coisa mais simples a fazer é iniciar seu release de desenvolvimento inicial na 0.1.0 e depois incrementar a versão secundária para cada release subsequente.

É bom passar de 0.3.0 direto para 1.0.0. Também é perfeitamente aceitável estar em 0.23.0. A partir de 0.4.0 é um pouco desaconselhável, pois sugere que houve versões publicadas anteriores.

Além disso, observe que isso 0.y.zé mantido de lado para iteração rápida, para que o desenvolvimento inicial (e, portanto, muitas mudanças de quebra) não o deixe em algo bobo como o 142.6.0. Em vez de bater na versão principal, bata a versão secundária em todas as alterações até que você libere a 1.0.0:

A versão principal zero (0.yz) é para o desenvolvimento inicial. Qualquer coisa pode mudar a qualquer momento. A API pública não deve ser considerada estável.

O número da versão é inteiramente sua. Faça o que faz sentido para você e seja consistente. Ninguém diz que você precisa começar de 0, 0,0 ou 1,0 ou 1,1.

Grandes programadores realmente usaram o sistema de numeração de versões como piadas locais. Exemplos (Wikipedia):

Desde a versão 3, o TeX usa um sistema de numeração de versão idiossincrático, em que as atualizações são indicadas adicionando um dígito extra no final do decimal, para que o número da versão se aproxime assintoticamente de π. Isso reflete o fato de que o TeX agora é muito estável e apenas pequenas atualizações são esperadas. A versão atual do TeX é 3.1415926; foi atualizada pela última vez em março de 2008

Para METAFONT:

O Metafont possui um sistema de versionamento semelhante ao do TeX, onde o número se aproxima assintoticamente de e a cada revisão.

Finalmente, não é um número de versão, mas igualmente interessante, é que a oferta pública inicial (IPO) do Google foi arquivada na SEC por arrecadar US $ 2.718.281.828 (observe que e ~ 2.718 281 828).

O que quero dizer é: não sinta que precisa seguir a multidão. Seja criativo e consistente.

Eu acho que diferentes fatores entram em jogo aqui. O impacto psicológico / de marketing do número da versão (o número da versão aumenta frequentemente => mais $$$, as pessoas não querem comprar uma versão beta com 0,99, etc.) deve ser levado em consideração. Os números de versão "lógicos" podem ajudar ao trabalhar em uma grande equipe.

E eu gosto da maneira linux de ter números ímpares para as versões instáveis ​​e números pares para a versão estável.

Quando obtenho minha primeira versão utilizável pronta, mas não a versão completa do recurso, normalmente tento avaliar quanto tempo leva para uma versão completa do recurso. Por exemplo, se o meu primeiro utilizável é 33% completo do recurso, faço o número da versão 0.3.0 ou semelhante. Então, conforme passo para o recurso, versões correspondentes completas recebem números de maneira semelhante.

Porém, depois de passar para o recurso anterior, o versionamento completo precisa ser alterado

Ao escolher números de versão para um npmpacote, lembre-se de que para dependências listadas em package.json intervalos semver não funcionará abaixo da v1.0.0. Isso é,

"dependencies": {
    "my-package": "^0.5"
}

é equivalente a

"dependencies": {
    "my-package": "0.5"
}

Se você deseja usar intervalos semver ou deseja que outras pessoas os usem, você pode começar com 1.0.0

Normalmente, o controle de versão tem algum significado para o programador. Aumentar o número principal pode indicar grandes alterações que impedem a compatibilidade com versões anteriores. Outros números no número da versão podem indicar pequenos aprimoramentos de recursos ou correções de erros.

Se você está preocupado que a versão 0.6.5 tenha um anel incompleto, convém comercializá-la na versão 1.0. O número da sua versão de marketing não precisa corresponder ao número da versão interna. O número da versão do Windows 7, por exemplo, é 6.1.

Minha preferência pessoal é começar a partir do 0.1.0 e partir daí.

Depende do projeto. Para ferramentas simples de linha de comando, geralmente inicio em torno de 0,9 [.0], pois só considero liberá-las ou empacotá-las quando elas estão quase concluídas (ou prontas para testes beta, pelo menos). Projetos mais complicados começam em 0,1 [.0] e alguns nunca vêem 1.0. Considero a 1.0 uma versão de lançamento (ou pelo menos uma versão beta ou candidato a lançamento testado localmente) e planejo de acordo.

Nos projetos de equipe, quem coloca a tag da primeira versão decide :).

0.1.0 é o que eu começo e subo a partir daí. Isso é o que eu adaptei para o Xploration By Adrian, embora nos meus primeiros anos eu fosse muito esporádico e usei 1.0.0, 0.0.1 e alguns outros. Mas eu recomendo começar em 0.1.0 e partir daí.

Por Semver, reserve a e c em abc para A. Você primeiro lançamento oficial e C. Correções e correções de bugs. Isso ocorre porque uma versão principal geralmente quebra o código mais antigo. E os patches simplesmente corrigem bugs. Tudo isso é preferência pessoal, 0.99.0 não significa que você precise ir para a 1.0.0, etc. Eu já vi algumas que vão até a 0.218.42.

Os números das versões devem ter significado para você, como Arrieta comentou corretamente antes.

Talvez seguindo algo como: Primeiro # é o lançamento do prefeito, Segundo # é o mesmo lançamento do prefeito com alguns recursos adicionados e Terceiro # é o mesmo lançamento do prefeito, com os mesmos recursos, mas com bugs corrigidos ou alterações pequenas (mas significativas o suficiente).

1.3.2 => 1ª versão, com mais recursos e alguns bugs corrigidos.

No entanto, para usuários finais, alguns estão acostumados a grandes números nas versões finais.

Por exemplo: Corel 8, para 8.0.0, 8.0.1, 8.2.2, etc. Corel 9, para 9.0.0 ... etc.

E, principalmente, é mais sobre estratégias de marketing como: Corel X5 em vez do Corel 15.0.2, por exemplo.

Eu diria que depende se o número da versão é para você ou para o cliente.

comece com 0.0.0 e prossiga a partir daí.

Comece com 1.1.1 e siga em frente.