Discourse n'expédie pas de version LTS

Général
1

Je n’étais pas au courant de la compatibilité discourse, c’est donc quelque chose que je devrai approfondir.

J’aimerais aborder cela, car il semble y avoir une énorme déconnexion entre la façon dont l’équipe Discourse conçoit la branche stable et la façon dont le reste de la communauté discourse/la communauté plus large des administrateurs de forums pense de l’offre stable de Discourse.

Principales raisons pour lesquelles la branche stable ne répond pas à la définition de LTS.

1) La branche stable est activement déconseillée par le personnel chaque fois qu’elle est mentionnée.

Je ne veux pas nécessairement pointer du doigt des contributeurs individuels, mais voici une sélection de publications du personnel pour montrer le thème :

Notez que dans certains aspects, tests-passed est plus stable que stable, car c’est ce que discourse.org utilise, donc c’est le mieux testé.

Ainsi, Discourse est dans un état de bêta perpétuel, ce qui signifie que nous travaillons toujours sur de nouvelles fonctionnalités et des améliorations. Dans notre cas, la bêta ne signifie pas instable ; nous hébergeons des sites avec des millions de pages vues mensuelles sur nos versions tests-passed et bêta.

La branche stable n’est pas nécessairement plus « stable » que tests-passed. Il s’agit plutôt de l’idée que les bugs sont connus, et elle sert de point de contrôle pour un ensemble spécifique de fonctionnalités et d’améliorations. Avec tests-passed, de nouveaux bugs peuvent être introduits, puis corrigés quelques commits plus tard.

Le message a été assez constamment que Discourse est en « bêta perpétuelle », ce que les utilisateurs en production / non développeurs ne veulent pas expérimenter.

Dans une recherche rapide sur DuckDuckGo des dix premiers liens pour “discourse stable”, aucun ne semble vraiment plaider en faveur de l’utilisation de la branche stable. Donc, quelle que soit sa qualité réelle, si le personnel guide universellement les gens à s’éloigner de la branche stable, cela donne une impression négative dans l’esprit des gens quant à son adéquation à l’usage.

La branche stable est peut-être excellente, mais si on nous dit sans cesse qu’il vaut mieux ne pas l’utiliser, nous ne la considérerons pas pour un déploiement sérieux.

2. Une LTS reçoit des correctifs de bugs au-delà des simples correctifs de sécurité.

Une LTS est quelque chose qui ne reçoit pas de mises à jour de fonctionnalités, mais qui reçoit des correctifs de bugs. Selon les propres commentaires du personnel, il ne semble pas y avoir d’efforts déployés dans Discourse pour réintégrer les correctifs de bugs pour les problèmes non liés à la sécurité. Peut-être que ce n’est pas vrai, mais c’est ce qu’on nous a dit.

3. Une LTS a des étapes d’installation simples.

Le guide d’installation ne mentionne même pas l’existence de la branche stable.

4. Une LTS est largement utilisée.

Avant votre publication, je n’avais pas entendu parler d’une utilisation généralisée de la branche stable. Est-elle également largement utilisée dans la nature ? Vu à quel point elle est cachée, j’en doute, mais je n’ai pas de métriques pour le dire. C’est un facteur important car il donne aux gens confiance pour utiliser la branche stable pour leurs déploiements en production.

5. Une LTS a un cycle de publication et des notes de mise à jour claires.

Je ne vois aucun endroit central où la branche stable est clairement documentée. (Je la manque peut-être !)

Mes attentes pour une LTS sont une page qui décrit :

  • Version de publication active actuelle
  • Notes de publication incluant :
    • Changements/fonctionnalités majeurs entre les versions LTS
    • Étapes de migration depuis la dernière version LTS (en particulier les changements majeurs à connaître)
    • Durée de support actif prévue pour chaque version

par ex. mediawiki, mais vraiment toute LTS open source majeure a des pages similaires.

Cette documentation m’aide à planifier lorsqu’il y a un changement majeur qui nécessitera une interruption de service et/ou une intervention manuelle.

6. Une LTS n’a pas de changements majeurs incompatibles au sein d’un cycle de publication.

C’est peut-être le cas pour la branche stable, mais je suis trop habitué à appuyer sur le bouton de mise à jour et à voir le forum tomber en panne pour le savoir avec certitude. Je suppose que ce que je cherche ici, ce sont des avertissements plus clairs lors du passage d’une version à une autre qui casse quelque chose.

7. Une LTS fournit des avertissements de dépréciation d’API pour au moins un cycle de publication LTS complet.

Ceux-ci devraient être mesurés sur une période d’un an ou plus, par opposition à un mois ou plus.

8. Une LTS est planifiée / a des périodes de support qui se chevauchent.

Toute LTS majeure aura une période de support qui se chevauche entre deux versions LTS. La branche stable semble simplement basculer de manière binaire vers la version suivante. (Mon impression peut également être erronée du fait qu’il n’y a pas de page de documentation centrale)

9. Il est simple de passer d’une version non-LTS à une LTS.

Il n’est pas nécessaire de prendre en charge le retour en arrière, mais lorsqu’une LTS est disponible, il n’est pas clair comment passer proprement d’une branche à une LTS. Il semble y avoir quelques publications sur le forum à ce sujet, mais là encore, aucune documentation centralisée que j’ai pu trouver.

Je suis un fan de Discourse, mais c’est un point de douleur courant que je rencontre et que beaucoup d’autres personnes rencontrent. Ce qu’est la branche stable actuellement n’est qu’une branche, pas une LTS.

4 « J'aime »
2

Déplacé ceci dans son propre sujet, semble sans rapport avec le regroupement de plugins.

3 « J'aime »
3

Si nous considérons le smiley triste dans le tableau de bord administrateur par rapport au fait d’être si loin derrière dans les commits pour « mettre à jour Discourse »

la mise à jour critique fait-elle partie de tests-passed et si vous « Tout mettre à jour » rapidement après que le smiley soit passé de content à triste, vous serez synchronisé avec tests-passed

4

Je pense que cette mise à jour spécifique nécessite une reconstruction depuis la console. Deux fois.

1 « J'aime »
5

Discourse semble avoir une vélocité assez élevée en termes de changements et une feuille de route ambitieuse.

Pour soutenir cela, il a besoin de beaucoup de retours d’utilisateurs. Je pense qu’il y a une stratégie implicite claire pour promouvoir tests-passed car cela soutient les retours précoces sur les nouveaux changements.

En retour, l’utilisateur obtient des logiciels gratuits et de nouvelles fonctionnalités. C’est une sorte de pacte. Je pense qu’au fil du temps, cet accord semble avoir fait ses preuves.

La version stable n’aide pas vraiment au développement autant, donc il n’est peut-être pas dans l’intérêt commercial de la promouvoir autant (ce n’est que mon opinion, je ne parle pas du tout pour CDCK).

L’autre problème avec la version stable est le suivant, et il est encore plus significatif :

Il y a généralement beaucoup de changements entre les versions stables, y compris des dépréciations importantes et des changements d’API. L’implication dans tests-passed en tant que développeur, administrateur de site ou créateur de thème vous donne une chance de gérer les changements en petits morceaux, au lieu d’avoir une énorme montagne à gravir à chaque fois que vous atteignez la prochaine étape stable.

Pour soutenir ces grands sauts, vous aurez probablement besoin d’un site de staging et d’un ensemble de cas de test à parcourir.

Si vous ne possédez aucune personnalisation vous-même, vous pourriez opter pour la version stable, mais vous dépendez fortement des autres sur lesquels vous n’avez peut-être aucune influence pour garantir que les modules complémentaires que vous utilisez sont suffisamment maintenus pour votre prochaine mise à niveau. Vous pourriez constater que certains éléments perdent leur support au moment de la mise à niveau et à ce moment-là, vous pourriez vous retrouver dans une situation difficile. Vous pourriez également constater que le développeur ne prend pas du tout en charge la version stable et que vous devrez peut-être forker et préparer une “coupe” du plugin pour prendre en charge votre version stable. (cependant, il existe un bon système d’épinglage en place, donc ce n’est pas une énorme quantité de travail)

L’autre élément significatif dans Discourse est son intensité en tests unitaires, donc la branche test-passed est généralement très bonne du point de vue de la stabilité.

4 « J'aime »
6

Étant donné le refus de la direction d’annuler des changements impopulaires comme le regroupement de plugins, je ne pense pas que cette partie soit exacte. Peut-être d’un point de vue QA, mais même dans ce cas, j’ai eu plusieurs bugs assez méchants qui n’ont pas été corrigés par le passé. Au final, je réalise qu’ils sont ceux qui investissent du temps et de l’argent dedans, donc ils peuvent prendre leurs décisions, mais à mon avis, je ne pense pas que ce soit une stratégie pour obtenir plus de retours.

Je pense que la raison la plus réaliste pour laquelle ils ne soutiennent pas un LTS approprié est que cela coûterait du temps à quelqu’un de l’équipe pour le gérer/documenter. C’est une fonctionnalité qui profite principalement aux auto-hébergeurs, donc j’imagine que ce serait considéré comme une perte de temps pour eux. Mais c’est une fonctionnalité assez attendue et ne pas l’avoir est un réel inconvénient lorsque les administrateurs de forums choisissent leur logiciel de forum, car d’autres contemporains ont des offres plus stables.

7

Au contraire, je pense que le regroupement de plugins vise précisément à en promouvoir l’utilisation et, par conséquent, à obtenir plus de commentaires.

8

La direction a spécifiquement mentionné des problèmes de décalage de version affectant la productivité de l’équipe de développement dans l’autre fil de discussion. Ce qui est une justification valable, mais pas la meilleure façon de résoudre le problème fondamental, comme discuté dans l’autre fil de discussion.