De Discourse 3.2: añadir sufijo -dev a versiones beta en desarrollo activo

En tests-passed, a partir de 3.2.0.beta1-dev, los números de versión principales de Discourse incluirán un sufijo -dev para indicar que no son las versiones ‘finales’ de una beta. Este sufijo no aparece en la interfaz de usuario, por lo que es una tecnicalidad que no tendrá impacto en la gran mayoría de las personas.

Para los detalles técnicos, véase a continuación:


En la serie beta de Discourse 3.1 y anteriores, nuestra estrategia de versionado consistía en ‘lanzar’ una beta y luego dejar el número de versión en tests-passed exactamente igual hasta el siguiente lanzamiento beta. Esto presentaba algunos problemas:

  1. Al intentar especificar una versión, una versión como 3.1.0.beta2 podría referirse a cientos de puntos posibles en el tiempo. Esto es particularmente problemático al intentar definir con precisión la compatibilidad a través de archivos .discourse-compatibility

  2. Después de una versión principal, tuvimos que ‘lanzar’ inmediatamente la beta1 de la siguiente versión para continuar el desarrollo en tests-passed. Es por eso que tuvimos lanzamientos beta1 redundantes

Para mejorar la situación, ahora añadiremos -dev al número de versión durante el desarrollo de una versión beta. Por ejemplo, comenzamos el ciclo de desarrollo 3.2 con 3.2.0.beta1-dev. Cuando esté listo para ser lanzado, se marcará como 3.2.0.beta1, y luego haremos un seguimiento inmediato con otro commit para iniciar el desarrollo de 3.2.0.beta2-dev.

En el futuro, pretendemos que los ‘lanzamientos principales’ se vean algo así:

    %%{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"

Los ‘lanzamientos menores’ se verán algo así:

    %%{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"

(se pueden considerar main y tests-passed como equivalentes en estos diagramas)

Estos procesos se han codificado en algunas tareas de rake que se pueden encontrar en version_bump.rake.

31 Me gusta

Aparece en la página /admin… pero encontrar este tema me tranquilizó.

1 me gusta

Si solo la numeración de las versiones es tan compleja (asignarla y que la entiendan usuarios como yo), ¡qué complejo debe ser el desarrollo de software!

Después de pasar unos 15 minutos, sobre todo esto de beta, estable, dev, tests-passed, backuporting, finalmente me rendí.

¡Qué demonios! ¡Que mi sitio web siga mostrando ‘Dev’!