Je sais que vous recommandez les tests réussis, mais je dois suivre la branche stable, et la 3.2.1 vient d’apparaître. Cependant, je me demande pourquoi elle apparaît comme 3.2.1 +9. La branche stable n’est-elle pas censée être sur le tag publié (du moins immédiatement après la publication) ?
D’après ma compréhension, v3.2.0 +9 signifie que quelques commits sont disponibles en plus de votre version actuelle (avant la 3.2.1).
v3.2.1 +5 signifierait que vous pouvez mettre à jour vers la version suivante, 3.2.1, et que quelques commits ont déjà été ajoutés en plus de cette version. Habituellement, je crois qu’il s’agirait de corrections importantes rétroportées depuis la branche principale.
Je comprends que cela puisse être déroutant au début. Je me demande si cela pourrait être amélioré.
ah ok, donc la colonne dépôt signifie « votre installation actuelle locale » - cela pourrait avoir du sens, merci. Et j’ai lu l’annonce 3.2.1 aujourd’hui, donc j’ai été surpris qu’il y ait déjà plus de commits, mais si c’est attendu, cela me convient aussi.
Une idée pourquoi le tableau de bord principal ne m’indique pas encore cette mise à jour ? (Je peux comprendre quand elle n’est actualisée que quotidiennement, mais elle aurait dû être mise à jour lorsque j’ai vérifié manuellement l’onglet « Mises à jour ».)
C’est exact, la prochaine étiquette de version est 3.2.1. Nous avons manqué quelques commits juste avant le changement, ils ont donc été ajoutés juste après, d’où le +5. Habituellement, nous nous assurons de faire un backport avant que l’étiquette ne soit émise, mais nous l’avons manqué cette fois-ci. Ça arrive.
Notez que les commits +5 corrigent les problèmes suivants :
une traduction pour guidelines_topic.body
une erreur avec les validations de clé de sécurité dans une ancienne version de Firefox (pas la dernière)
le style des espaces réservés pour les vidéos
L’identifiant de commit que vous obtiendrez après la mise à jour est 6a0aa03@ecki, il inclut les corrections ci-dessus.
L’écran « Mises à jour » provient du plugin de gestion Docker, le tableau de bord principal est la vérification du cœur, qui ne se produit qu’une fois par jour. Les deux ne communiquent pas, d’où la divergence. (Bon point, cependant, ce serait bien s’ils communiquaient.)
Pendant que nous y sommes, existe-t-il un mécanisme pour décider quand une reconstruction doit être effectuée, par exemple pour les mises à jour d’urgence des conteneurs de base/db/données, ou cela n’est-il jamais signalé dans le tableau de bord des mises à jour du frontend ?
