Ok, mais je pense alors que je comprends encore moins le problème
Finalement, peu importe puisque d’après les derniers commentaires de @david, pour résumer.
Le modèle proposé est une sortie mensuelle, plus 2 versions esr, donc par exemple pour 2026 :
2026.1
2026.2
2026.3
…
2026.8
2026.9
2026.10
…
Donc en supposant que nous soyons en octobre 2026 et que .2 et .8 soient des versions esr, cela signifie 4 versions prises en charge.
Et ma pensée était. Ne serait-il pas plus facile d’avoir essentiellement des versions trimestrielles, c’est-à-dire pour 2026 :
2026.1
2026.2
2026.3
…
Et que seules la version actuelle et la version précédente seraient prises en charge, donc en octobre 2026, ce serait 2.
Et tout le raisonnement était que cela pourrait peut-être faciliter les choses pour les développeurs et les utilisateurs. Mais comme mentionné ci-dessus : @david a précisé que des sorties moins fréquentes ne sont pas une option.
Compris. C’est à peu près ce à quoi je m’attendais. En effet, dans ce cas, un peu de support d’outils serait agréable au moins à moyen terme.
La façon dont je le conceptualise, c’est : vous êtes sur un canal de diffusion spécifique (latest, release, esr), et généralement vous passeriez relativement rapidement à la prochaine diffusion, donc recevoir un message et/ou une notification lorsque la nouvelle diffusion est disponible et avoir une seule commande pour y passer serait génial. Et pour les cas où vous avez retardé l’adoption d’une nouvelle diffusion, il serait également agréable d’être rappelé lorsque la diffusion actuellement utilisée devient obsolète/non prise en charge. Points bonus si l’outil respectif pouvait également vous permettre de changer rapidement de canal de diffusion
Mais je comprends si ce n’est pas la priorité absolue pour le moment, et que vous recommandez toujours aux gens de rester sur test-passed/latest.
Je vois. Dans le contexte de mon travail, proposer une fonctionnalité aux clients est considéré comme “rapide”
De plus, comme mentionné ci-dessus, je pensais qu’un passage à un calendrier trimestriel faciliterait en fait votre vie (et celle des développeurs de plugins/thèmes), car il y a moins de branches à maintenir. Donc, si ce n’est pas le cas, alors je suppose que cela n’a vraiment pas de sens pour vous
SemVer n’est pas vraiment conçu pour les grandes applications. Je comprends qu’il soit beaucoup plus ciblé sur les bibliothèques consommées par les logiciels, et en particulier, la logique de numérotation des versions est construite autour de l’API du package.
Nous pourrions cependant appliquer SemVer à notre ou nos API. Avoir des garanties plus solides autour des API que Discourse expose est certainement une conversation intéressante à avoir, mais je pense qu’elle est distincte de celle-ci.
Maintenant, je comprends que vous n’avez pas dit que nous devrions être conformes à SemVer - vous avez juste dit que nous devrions continuer à utiliser des nombres conformes au système de numérotation spécifié par SemVer.
Un numéro de version normal DOIT prendre la forme X.Y.Z où X, Y et Z sont des entiers non négatifs, et NE DOIVENT PAS contenir de zéros non significatifs. X est la version majeure, Y est la version mineure et Z est la version de correction. Chaque élément DOIT augmenter numériquement. Par exemple : 1.9.0 → 1.10.0 → 1.11.0.
Je pense que la suggestion concernant les « zéros non significatifs » est la seule chose que nous enfreindrions si nous empruntions cette voie.
Sinon, je pense que toute bibliothèque SemVer serait toujours capable d’analyser les numéros de version que nous suggérons et de les trier correctement.
Cela dit, pouvez-vous m’en dire plus sur pourquoi vous pensez qu’être conforme à un système de numérotation SemVer a de la valeur ?
L’OP dit que vous n’utilisez pas de zéros non significatifs, si je comprends bien.
Je pense qu’une raison convaincante d’utiliser des zéros non significatifs (tri par versions) a également été proposée. Les zéros non significatifs sont-ils le plan actuel ? (J’aime toujours les versions mensuelles plutôt que les versions en série).
Le but de SemVer est que le numéro de version communique des informations utiles. La seule information communiquée par votre schéma proposé est l’orbite de la Terre autour du Soleil. Cette information n’est pas très utile au consommateur du logiciel.
Si pour une raison quelconque je voulais connaître la date de publication, je regarderais la publication et obtiendrais la date complète.
Pas vraiment. Le but est de communiquer la nature de la publication à l’utilisateur.
Si la publication est une augmentation de version de correctif, cela communique que le changement ne contient rien qui devrait affecter le flux de travail des utilisateurs du logiciel.
Si la publication est une augmentation de version mineure, cela communique que le changement inclut l’ajout de nouveaux composants visibles par l’utilisateur, mais rien qui ne perturbera les flux de travail existants des utilisateurs du logiciel.
Si la publication est une augmentation de version majeure, cela communique que le changement inclut des modifications qui pourraient perturber les flux de travail existants des utilisateurs du logiciel.
La détermination du composant de version à augmenter est plus claire dans un produit logiciel doté d’une interface utilisateur unique, mais les principes restent les mêmes, même pour un produit logiciel comme Discourse, où il existe une variété de niveaux d’interfaces et de types de consommateurs (par exemple, développeurs de plugins, consommateurs d’API, personnel du forum, utilisateurs finaux).
Même si le choix du composant à augmenter est un peu plus subjectif dans ce projet logiciel, il en résulte toujours que le numéro de version a un sens au lieu d’être simplement un nombre arbitraire, comme c’est le cas avec votre proposition.
Contrairement à semver, le schéma de numérotation de version proposé permet de savoir immédiatement si une version est toujours prise en charge (comme Ubuntu). Puisque cela dépend aussi de l’orbite de la Terre autour du soleil, cela a du sens.
Ceci est clairement destiné aux paquets et aux bibliothèques. Toute version de Discourse inclut des changements qui peuvent casser les flux de travail existants des utilisateurs du logiciel. J’ai même vu des correctifs de sécurité le faire. Semver n’est pas utilisable pour des applications complexes.
Une fois que vous avez identifié votre API publique, vous communiquez les changements qui lui sont apportés avec des incréments spécifiques à votre numéro de version.
Pour souligner un point qui pourrait passer inaperçu, je pense que Discourse fait un excellent travail ici. Une amélioration serait au moins de mettre en évidence les sujets que vous avez déjà écrits qui décrivent les changements et les problèmes potentiels au sein de ce cycle de mise à niveau. Par exemple, avec la version 3.5, j’ai dû ouvrir les notes de version, cliquer sur le blog, puis cliquer par hasard sur le lien concernant le regroupement de plugins avec Discourse core pour saisir ce détail selon lequel laisser ces plugins dans mon fichier de configuration pourrait avoir un impact sur les mises à niveau.
Il serait formidable de retirer ces types de notes sur une page/un sujet pour les versions ESR, même s’il ne s’agit que d’un ensemble de liens vers des sujets existants qui devraient être examinés avant d’effectuer une mise à niveau ESR.
Cela dépasse peut-être la portée de ce fil de discussion - mon commentaire sur le changement de version est que je l’accueille favorablement et que j’apprécie la transparence ici. Je pense que ce serait une excellente amélioration qui simplifierait les choses tout en nous donnant plus d’options pour l’auto-hébergement.
Les zéros non significatifs et la question de savoir s’il faut viser une synchronisation plus explicite avec les mois sont à l’étude. @david partagera une mise à jour une fois que le groupe qui travaille sur ce sujet sera parvenu à une décision.
Ce n’est pas l’information importante pour un mainteneur de forum qui évalue une nouvelle version.
Non, vraiment. Vous manquez le véritable objectif de SemVer en refusant de comprendre que « API » signifie en fait juste l’interface. Il n’y a absolument aucune raison pour que l’esprit de SemVer ne puisse pas être utilisé dans le versionnage de tout type de logiciel.
Semver n’est pas vraiment utile pour les « applications grand public », il est plus utile pour les bibliothèques que les gens utilisent comme dépendances pour leurs projets.
Peu importe qu’il s’agisse d’une bibliothèque ou d’une application plus grande. Un schéma de versionnement sémantique fonctionne parfaitement bien pour une grande application. Il peut même être utilisé pour une collection d’applications regroupées dans une plateforme, mais ici, cela devient assez difficile à gérer.
La question principale est de savoir si vous optez pour la voie de la dépréciation prise en charge dans une version et seulement la suppression dans la prochaine version majeure. Avoir une fonctionnalité dépréciée mais prise en charge peut demander beaucoup d’efforts. Lorsque vous allez apporter des modifications à votre modèle de données persistant, la dépréciation peut souvent devenir impossible. Si cela se produit, vous ne pouvez même pas faire une version mineure avec une fonctionnalité dépréciée, et vous passez instantanément à une nouvelle version majeure. C’est là que les grandes applications ont généralement des problèmes. Vous passez de 3.0.0 à 3.0.1 à 4.0.0 car vous ne pouvez pas assurer la rétrocompatibilité. Si vous avez souvent des changements majeurs, s’en tenir à semver ajoute peu de valeur.
Cela dit. Je préfère beaucoup cette construction car elle communique plus clairement aux développeurs qu’il y aura des changements majeurs. Le schéma AAAA.N ne me dit rien en tant que développeur, ni en tant qu’administrateur.
La question est donc, que voulez-vous communiquer avec la version ? Si vous voulez faire 6 versions de fonctionnalités (qui peuvent ou non être majeures), et que toutes les 6 versions seront plus longtemps prises en charge avec des correctifs ; et que vous ne voulez pas versionner les versions de correctifs. Alors X.Y est un schéma approprié où Y=0 est celui qui est plus longtemps pris en charge. X serait juste un nombre. Le problème est que lorsque X est l’année, Y est rapidement associé à un mois. Donc les nouvelles versions plus longtemps prises en charge sortiront en janvier ? Je dois toujours chercher quelle version d’Ubuntu est une LTS, ce qui m’agace.
Alors, que se passe-t-il si Discourse continue simplement avec la version majeure actuelle. La prochaine version plus longtemps prise en charge s’appelle 4.0 ; et ensuite nous obtenons 4.1 à 4.5 comme versions de fonctionnalités ; suivies de 5.0 qui est la plus récente version plus longtemps prise en charge.
Alors vous n’aurez pas non plus ce moment gênant où une version est retardée à cause d’un problème majeur.
Vous pourriez éventuellement ajouter un numéro de « correctif » si vous prévoyez de publier explicitement des correctifs (au lieu d’avoir des correctifs continus). « Mais alors vous avez x.y.z qui est semver ». Eh bien non, cela ressemble à semver, mais ce n’est pas le cas. Chaque nouvelle version « mineure » peut être majeure. Je suggère donc de s’en tenir au schéma de version X.Y avec Y=0 → LTS.
Indépendamment de la chaîne de version. J’aime bien le nouveau plan de publication.
Cette discussion n’est pas reluisante. Je vois une décision de l’équipe de développement d’adopter un nouveau système de versionnement qui a du sens pour eux, et d’autres qui semblent soudainement considérer que la version de Discourse suivait le versionnement sémantique… ce qui n’était pas le cas. Il s’est toujours agi d’une version “rolling release”, du moins depuis la 1.0, ou bien ?
Mais les arguments de tous les partis dans le débat semblent erronés :
« norme industrielle » : Linux utilise des versions paires pour les versions stables et impaires pour les versions de développement.
« la Terre tourne autour du Soleil » : eh bien, si vous vous convertissez à l’Islam, vous aurez des ennuis car vous abandonnerez les versions et non, cela ne correspondra plus à la révolution du Soleil, mais aux cycles de la Lune. Ici, vous comprenez maintenant qu’en choisissant le schéma de versionnement AAAA.M.Z plutôt que X.Y.Z, vous avez imposé une culture dominante.
La version mineure reste floue : vous mentionnez « en supposant une cadence mensuelle », mais cela pourrait tout aussi bien être 3 semaines ou 7, en fonction de la fonctionnalité, auquel cas compter A de 0 a du sens, ou visez-vous réellement à publier mensuellement, auquel cas compter M à partir de 1 aurait plus de sens ?
Le principal changement que je vois est qu’en adoptant un rythme mensuel, l’équipe Discourse définit des attentes et s’éloigne des objectifs de publication, adoptant plutôt des publications régulières.
LTS pendant 8 mois ne semble pas vraiment “long”. NodeJS évolue trop vite, mais ils maintiennent le support LTS sur plus de 30 mois et plusieurs versions actuelles à la fois, tandis qu’Ubuntu maintient LTS pendant des années. Bien que je comprenne que Discourse n’est ni un langage ni un système d’exploitation, cela semble annoncer que de nouvelles fonctionnalités seront livrées à un rythme assez rapide, ce qui soulève une autre question : comme de nouveaux paramètres d’administration sont introduits de temps en temps, nous allons bientôt tomber dans l’enfer de Wordpress avec des options infinies et une complication insondable pour l’administration du site, alias bloatware : il devient alors important de clarifier comment vous passez des versions existantes avec des objectifs à des versions régulières, et comment vous choisissez les objectifs à abandonner (ou reporter) pour une version, etc. (ce qui est peut-être déjà documenté, mais j’ai manqué cela.)
Auriez-vous l’amabilité de partager votre raisonnement entre le rythme de développement / versionnement, et ce que vous avez en tête pour éviter que les administrateurs ne se noient sous trop de paramètres et une courbe d’apprentissage accrue ?
Avant de répondre à vos autres questions, je tiens d’abord à préciser que notre fréquence de publication prévue ne change pas avec cette proposition.
Au cours des 3 dernières années, nous avons effectué des versions « stables » environ tous les 6 mois, ciblant ces versions pour la fin de chaque janvier et juillet, avec quelques décalages ici et là :
Au cours des ~8 derniers mois, nous avons effectué des versions « bêta » environ tous les mois, à l’exception de quelques versions de sécurité hors bande :
Dans cette nouvelle proposition, nous avons l’intention de conserver la même cadence que nous avons suivie, les principaux changements étant :
Ce que nous appelons maintenant des versions « stables », nous les appellerons « versions de support étendu »
Nous avons choisi ce nom et non support à long terme, car nous convenons qu’il est étendu par rapport à nos autres versions prises en charge, mais pas nécessairement à « long terme ». Cette proposition n’inclut pas l’ajout d’une version de support à long terme.
Actuellement, le support d’une version stable se termine immédiatement lorsque la version suivante est publiée. Avec cette nouvelle proposition, le support se chevauche pendant environ 2 mois, afin que les utilisateurs aient le temps de mettre à niveau tout en recevant des correctifs de sécurité.
Ce que nous appelons maintenant des versions « bêta », nous les appellerons « versions »
Nous ne prenons actuellement en charge aucune version bêta au-delà de sa date de publication. Ce ne sont que des points de contrôle en cours de route qui s’accompagnent d’une notification pour accélérer, car ils incluent souvent des correctifs de sécurité.
Avec cette proposition, nous avons l’intention de prendre en charge les versions pendant environ 2 mois, afin que les utilisateurs puissent décider quand mettre à niveau, tout en continuant à recevoir des correctifs de sécurité.
Dans cette optique, pensez-vous que vos autres questions sur le trop grand nombre de paramètres sont toujours liées à cette proposition ? Ou s’agit-il de préoccupations indépendantes qui seraient mieux discutées dans un sujet distinct ?
Merci pour votre explication détaillée @mcwumbly !
En effet, il s’agit d’une préoccupation différente. La personnalisation de l’administrateur à l’aide d’un plugin serait utile pour faire des tests sur ce à quoi cela pourrait ressembler. Y a-t-il des travaux en cours concernant une telle approche ?
Pas spécifiquement cela, mais nous avons investi pas mal d’efforts dans l’amélioration de l’interface utilisateur de l’admin au cours de la dernière année. Si vous souhaitez approfondir ces sujets, pouvez-vous créer un nouveau sujet et exposer certains des problèmes et/ou idées que vous aimeriez discuter davantage ?
C’est un excellent changement (j’aime particulièrement les ESR qui se chevauchent)
Commentaires :
J’aimerais voir ce graphique de cycle de vie sur une page centralisée afin de pouvoir le consulter facilement, idéalement avec un tableau EOL pour pouvoir dire facilement ce qui est pris en charge et ce qui ne l’est pas à tout moment et planifier en conséquence (au moins pour les ESR).
Changement de flux :
Ce serait génial – mais même juste pouvoir choisir le tag lors de la configuration serait énorme. Ou même simplement inclure les étapes manuelles dans la documentation de configuration. Si quelqu’un veut commencer sur stable/ESR, il n’est pas vraiment clair comment faire cela pour un nouvel administrateur. (Je pense que la réponse est de passer –skip-rebuild à ./launcher, puis de modifier la version, puis de faire un rebuild pour la première fois, mais je ne suis pas sûr.) Sinon, la configuration lance immédiatement la récupération et l’exécution de la dernière version, et revenir en arrière est source de problèmes.
(Exemple de la difficulté pour un nouvel administrateur : Actuellement, le premier résultat de recherche pour « installer discourse stable » dirige vers ce fil de discussion, qui renvoie à un autre fil expliquant comment mettre à niveau vers stable, mais pas comment installer stable à partir de zéro.)
