Je gère plusieurs sites Discourse depuis un certain temps et j’ai un certain nombre de scripts qui interagissent directement avec certaines des API de Discourse. Je constate que périodiquement, les choses cessent de fonctionner après une mise à niveau. En général, cela ne pose pas de problème si les problèmes sont détectables immédiatement, mais lorsqu’ils n’apparaissent que plus tard, il devient difficile de les résoudre et cela entraîne souvent des problèmes de production plutôt que des problèmes sur les instances de développement.
Par exemple : Recurring events in Upcoming Events calendar fail to handle daylight saving change
Récemment, l’option include_expired a été supprimée. Malheureusement, le comportement consistant à ne retourner que les événements non expirés de l’API du calendrier était quelque chose sur lequel je comptais, et cela a provoqué l’échec d’un certain nombre de processus à une date ultérieure, après la mise à niveau. Pour cet exemple particulier, échouer si un appelant spécifiait le paramètre maintenant supprimé aurait au moins arrêté le problème dans mon script particulier ![]()
Je me demande donc, en tant qu’utilisateur en aval de Discourse, quelle est la meilleure façon d’identifier les changements d’API comme ceux-ci avant qu’ils n’affectent mon instance ? Auparavant, j’ai eu recours à la duplication du dépôt discourse-calendar et à sa mise à niveau moins fréquemment de mon côté pour éviter ces problèmes. Maintenant qu’il est intégré, j’ai décidé d’abandonner cette approche et je me fais à nouveau avoir.
J’apprécie tout le travail et les améliorations constants apportés à Discourse, et cela me convient si la réponse est “inscrivez-vous à l’offre entreprise et ces choses se produiront moins fréquemment”, ou si vous ajoutez plus de tests de votre côté, mais je voulais voir s’il existe peut-être d’autres options ou approches que j’ignore.
Merci.