Da Discourse 3.2: adicionando o sufixo -dev às versões beta em desenvolvimento ativo

Em tests-passed, a partir de 3.2.0.beta1-dev, os números de versão do core do Discourse incluirão um sufixo -dev para indicar que não são as versões finais de ‘release’ de um beta. Este sufixo não aparece na UI, então esta é uma tecnicalidade que não terá impacto na grande maioria das pessoas.

Para os detalhes técnicos, veja abaixo:


Na série beta do Discourse 3.1 e anteriores, nossa estratégia de versionamento era ‘lançar’ um beta e, em seguida, deixar o número de versão em tests-passed exatamente o mesmo até o próximo lançamento beta. Isso veio com alguns problemas:

  1. Ao tentar especificar uma versão, uma versão como 3.1.0.beta2 poderia se referir a centenas de pontos no tempo possíveis. Isso é particularmente problemático ao tentar definir precisamente a compatibilidade através de arquivos .discourse-compatibility

  2. Após uma versão principal, tivemos que ‘lançar’ imediatamente o beta1 da próxima versão para continuar o desenvolvimento em tests-passed. É por isso que tivemos lançamentos beta1 redundantes

Para melhorar a situação, agora anexaremos -dev ao número de versão durante o desenvolvimento de um lançamento beta. Então, por exemplo, estamos começando o ciclo de desenvolvimento 3.2 com 3.2.0.beta1-dev. Quando estiver pronto para ser lançado, será marcado como 3.2.0.beta1, e então faremos um acompanhamento imediato com outro commit para iniciar o desenvolvimento de 3.2.0.beta2-dev.

Daqui para frente, pretendemos que os ‘lançamentos principais’ se pareçam com isto:

    %%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
    gitGraph
       branch stable order: 1
       commit tag: "v3.1.8"
       checkout main
       commit id: "bump to v3.2.0.beta17" tag: "v3.2.0.beta17" type: HIGHLIGHT
       commit id: "bump to v3.2.0.beta18-dev"
       commit
       commit id: "bump to v3.2.0.beta18" tag: "v3.2.0.beta18" type: HIGHLIGHT
       checkout stable
       merge main id: "merge"
       commit id: "bump to v3.2.0" type: HIGHLIGHT tag: "v3.2.0"
       checkout main
       commit id: "bump to v3.3.0.beta1-dev"

‘Lançamentos secundários’ se parecerão com:

    %%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
    gitGraph
       branch stable order: 1
       commit tag: "v3.1.1"
       checkout main
       commit id: "bump to v3.2.0.beta2-dev"
       commit id: "... development of beta2 ..."
       commit id: "bump to v3.2.0.beta2" tag: "v3.2.0.beta2" type: HIGHLIGHT
       checkout stable
       commit id: "backports"
       commit id: "bump to v3.1.2" type: HIGHLIGHT tag: "v3.1.2"
       checkout main
       commit id: "bump to v3.2.0.beta3-dev"

( main e tests-passed podem ser considerados equivalentes nesses diagramas)

Esses processos foram codificados em algumas tarefas rake que podem ser encontradas em version_bump.rake.

31 curtidas

Ele aparece na página /admin… mas encontrar este tópico me tranquilizou.

1 curtida

Se apenas a numeração das versões é tão complexa (para atribuir e para ser entendida por usuários como eu), quão complexo seria o desenvolvimento de software!!!

Depois de gastar cerca de 15 minutos em tudo isso de beta, estável, dev, testes-passados, backuporting, eu finalmente desisti.

Que diabos! Deixe meu site continuar mostrando ‘Dev’!!