OK – j’ai toujours voulu savoir cela, alors je vais demander…
Je reçois des emails de notre instance Discourse m’informant qu’une « nouvelle version » est disponible.
Elle contient un lien « Voir les nouveautés dans les notes de version… ».
Mais lorsque je clique sur le lien, aucune mention de cette nouvelle version ni de ses notes de version n’apparaît.
Regardez ici – il était indiqué que la nouvelle version était la 2.5.2, mais regardez maintenant l’écran vers lequel pointe le lien : voyez-vous une quelconque mention des notes de version de la 2.5.2 ?
Merci, mais juste pour être sûrs d’être sur la même longueur d’onde…
Le lien indique qu’il me redirige vers les notes de version 2.5.2. Or, ce n’est pas le cas. Nulle part sur cette page ou dans ce lien n’est mentionné les notes de version 2.5.2.
La même chose s’est produite lors de la dernière annonce.
Nous ne publions généralement pas de notes de version pour les mises à jour stables, car elles ne comportent que des modifications extrêmement mineures, des corrections de bugs essentielles rétroportées, etc. Il est possible d’extraire les modifications stables de GitHub via un lien spécial ; @jomaxro a peut-être une idée à ce sujet.
Nous recommandons généralement de rester sur la branche tests-passed, car tous nos clients et hébergeurs l’utilisent.
Jeff a raison, je ne rédige pas de notes de version pour les versions stables. L’e-mail que vous avez reçu est un message standard, partagé par toutes les instances Discourse. Il ne sait pas sur quelle branche vous vous trouvez.
Les versions correctives stables incluent uniquement des correctifs de bugs critiques et des mises à jour de sécurité. Contrairement à nos versions normales, qui contiennent des centaines de modifications, les versions correctives stables comportent généralement moins de 10 changements, et souvent beaucoup moins.
Vous pouvez consulter l’ensemble des modifications à l’adresse https://github.com/discourse/discourse/commits/stable. Recherchez « Version bump to v{version actuelle} » et « Version bump to v{version précédente} ». Tout ce qui se trouve entre les deux correspond aux modifications. Dans le cas de la version 2.5.2, il y a 7 changements : 3 liés à la sécurité, 2 suite à ces correctifs de sécurité, et 2 correctifs critiques de performance.
C’est compris. Votre raisonnement pour ne pas publier de notes de version pour les versions stables a du sens. Mon seul point est que BEAUCOUP d’entre nous reçoivent des notifications par e-mail et, dans la MAJORITÉ des cas, le lien vers les notes de version ne contient rien à dire. Une option serait de modifier le modèle pour mieux définir les attentes, plutôt que de me faire du teasing et de cliquer généralement pour ne rien trouver en rapport avec l’e-mail que je viens de recevoir.
Si c’était notre produit, je prendrais 10 minutes pour créer une note de version pour chaque sortie.
Il suffirait de dire : « Il s’agit d’une version mineure. Faible risque. Principalement des corrections de bugs. Cependant, nous avons modifié la façon dont xxx est géré, si vous souhaitez être informé de cette amélioration ou de son impact potentiel. »
Je propose de mettre à jour le modèle de courriel standard pour les mises à jour :
Remplacer
« Découvrez ce qui est nouveau dans les notes de version »
par
« Fouillez dans ces notes de version et essayez de comprendre ce qui est inclus dans cette nouvelle version, car il n’y a pas de notes de version pour cette version »
Contexte
J’ai reçu aujourd’hui un autre courriel indiquant que la version 2.7.1 est disponible et invitant à consulter le lien des notes de version, qui ne contient pas de note pour la version 2.7.1. Le lien devrait être utile ou supprimé.
Nous avons eu une discussion interne. Comme je suppose que tu le comprendras, nous n’allons pas modifier le texte comme tu l’as proposé. Bien que nous recommandions toujours que les sites restent sur tests-passed, comme par défaut, nous allons créer des notes de version pour les versions stables à l’avenir. Notez que ces notes ne contiendront pas le même niveau de détail que les notes de version normales, car les mises à jour stables n’incluent que des correctifs de bugs critiques et des correctifs de sécurité.
Très bien. Je m’excuse d’avoir été sarcastique, mais dès que je reçois l’avis de nouvelle version, j’ai immédiatement envie de cliquer sur le lien pour voir comment cette version peut affecter mes utilisateurs et quelle est la priorité de la mise à niveau, etc. Mais je suis toujours frustré car le lien ne fait pas cela et, dans la plupart des cas, il n’y a jamais de documents avec le même numéro de version référencés dans la mise à niveau. Je dois donc maintenant décider combien de temps consacrer à la recherche de documents spécifiques à cette version, etc. Évidemment, un document contenant « bêta » ou un numéro de version antérieur peut être très différent de la version finale, donc ces documents ne m’ont aucune utilité.
Pour référence future, le journal des modifications effectif pour une mise à jour majeure stable, telle que 2.5.0, correspond à la somme de toutes les versions bêta commençant par la version : 2.5.0.beta[1,2,3,4,5,6,7]. Nous nous efforçons de maintenir les versions « bêta » utilisables à tout moment, et notre branche « stable » est davantage axée sur l’absence de changements que sur l’absence de bogues.
Espérons que les notes de version de la correction aideront à dissiper la confusion.
