Depuis Discourse 3.2 : ajout du suffixe -dev aux versions bêta en cours de développement

Sur tests-passed, à partir de 3.2.0.beta1-dev, les numéros de version principaux de Discourse incluront un suffixe -dev pour indiquer qu’il ne s’agit pas des versions finales de ‘release’ d’une bêta. Ce suffixe n’apparaît pas dans l’interface utilisateur, il s’agit donc d’une technicité qui n’aura aucun impact sur la grande majorité des utilisateurs.

Pour les détails techniques, voir ci-dessous :


Dans la série bêta de Discourse 3.1 et versions inférieures, notre stratégie de versionnement consistait à ‘publier’ une bêta, puis à laisser le numéro de version dans tests-passed inchangé jusqu’à la prochaine version bêta. Cela posait quelques problèmes :

  1. En essayant de spécifier une version, une version comme 3.1.0.beta2 pouvait faire référence à des centaines de points dans le temps possibles. C’est particulièrement problématique lorsque l’on essaie de définir précisément la compatibilité via les fichiers .discourse-compatibility

  2. Après une version majeure, nous devions immédiatement ‘publier’ la bêta1 de la version suivante afin de continuer le développement sur tests-passed. C’est pourquoi nous avions des versions bêta1 redondantes

Pour améliorer la situation, nous allons maintenant ajouter -dev au numéro de version pendant le développement d’une version bêta. Par exemple, nous commençons le cycle de développement 3.2 avec 3.2.0.beta1-dev. Lorsqu’elle sera prête à être publiée, elle sera estampillée 3.2.0.beta1, puis nous ferons immédiatement un commit pour commencer le développement de 3.2.0.beta2-dev.

À l’avenir, nous prévoyons que les ‘versions majeures’ ressembleront à ceci :

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

Les ‘versions mineures’ ressembleront à ceci :

    %%{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 et tests-passed peuvent être considérés comme équivalents dans ces diagrammes)

Ces processus ont été codifiés dans quelques tâches rake que vous pouvez trouver dans version_bump.rake.

31 « J'aime »

Il apparaît bien sur la page /admin… mais trouver ce sujet m’a rassuré.

1 « J'aime »

Si la simple numérotation des versions est si complexe (à attribuer et à comprendre par des utilisateurs comme moi), à quel point le développement logiciel serait-il complexe !!!

Après avoir passé environ 15 minutes sur tout cela : bêta, stable, dev, tests-passés, backporting, j’ai finalement abandonné.

Bon sang ! Laissez mon site web continuer à afficher « Dev » !!