Pourquoi une mise à jour de documentation = une mise à jour du plugin?

La question est dans le titre : on voit régulièrement passer des mises à jour de plugin mineures, et le changelog rappelle généralement que « s’il n’y a pas d’information sur la mise à jour, c’est que celle-ci concerne uniquement de la mise à jour de documentation, de traduction ou de texte. »

En tant que néophyte j’ai du mal à voir pourquoi la mise à jour de la documentation, qui n’est pas contenue dans le plugin mais généralement sur une page internet externe, implique forcément une mise à jour du plugin ?
Ou alors c’est moi qui comprend mal, et il n’y a jamais de mise à jour uniquement de la doc, mais généralement les modifs mineures sont aussi une opportunité de mettre à jour la doc ?

Salut,

Alors si la documentation est bien incluse dans le plugin, l’idée étant d’être en mesure d’y accéder pour la consulter sans qu’il soit obligatoire d’avoir accès à internet.

Exemple avec le plugin template :
plugin-template/docs/fr_FR at master · jeedom/plugin-template (github.com)

1 « J'aime »

Donc quand j’ouvre par exemple cette page externe, ça va chercher des infos dans mon plugin :thinking: ? Ou alors c’est juste deux endroits qui reprennent les mêmes infos dispos sur github ?

Salut,

A ma connaissance il n’y a aucun cas où la doc va s’afficher depuis les fichiers en local (mais si on veut/doit on peut y accéder)

Pour les plugins le template de base prévoit la doc dans le plugin; c’est facile/clé en main pour un nouveau dev de prendre le template et il y a tout ce qu’il faut dedans.
Ensuite sous github c’est facile d’avoir un « site de doc » (github pages) par repo (un plugin = un repo)

et s’il y a plusieurs intervenant sur un même plugin, niv organisation c’est probablement plus simple d’avoir tout dans le même repo aussi: le dev fait sont changement, ouvre le changelog et/ou la doc juste à coté pour décrire le changement et commit tout d’un coup
sinon faudrait ouvrir un autre repo pour la doc et un dev c’est paresseux…

après ca reste un choix. Moi (et plusieurs autres dev également) j’ai pris la décision de ne plus mettre la doc dans le repo de mes plugins mais j’ai un repo dédié (mais je suis tout seul à maintenir…):

  • les plugins sont plus léger à télécharger
  • pas d’update intempestif parce que je change la doc (et j’évite les questions du coup)
6 « J'aime »

Je n’aurai jamais fait une réponse aussi précise et complète que celle de @Mips, tout est dit.

@rom.jou, dans la cas du plugin jMQTT que tu prends en exemple, la documentation est bien incluse directement dans le plugin :
jMQTT/docs/fr_FR at beta · Domochip/jMQTT (github.com)

1 « J'aime »

Ok merci à toi et @mips, je comprends un peu mieux : en fait le code ET la doc sont sur git, et donc la doc est incluse dans le plugin. Mais du coup le maillon qui manque encore dedans les neurones c’est le lien entre la page git (celle de Jmqtt par exemple) et la page qui s’affiche quand on clique sur Documentation dans le plugin (celle que j’ai indiquée, qui apparaît bien comme une page externe dans mon navigateur).

qui est une page externe :wink:

github pages c’est un système pour créer et déployer automatiquement un site web (statique) à partir de fichier markdown (.md) par exemple
on configure notre repo pour dire à github où se trouve la doc et automatiquement, chaque fois que le fichier source .md est modifié, github va déployer une nouvelle version du site (en générant les pages html)

par défaut l’url de base du site sera toujours https://[repo_owner].github.io/[repo_name] => https://domochip.github.io/jMQTT

et on configure cette url dans le fichier plugin_info\info.json de notre plugin (ici pour jmqtt: https://github.com/Domochip/jMQTT/blob/beta/plugin_info/info.json) ainsi le core la connait et peut afficher le bouton sur le market ou sur ton jeedom

2 « J'aime »

Si je comprends, quand la doc est mise à jour, une mise à jour logiciel (alerte mise à jour dans Jeedom) est associée même s’il n’y a aucune modification ?

Personnellement, ce que je regrette c’est justement la mention qui dit que l’on peut avoir une mise à jour sans l’inscrire dans le change log. ça me laisse dans l’expectative et pour certains plug-in je ne fais pas de mise à jour pour limiter les risques ou je fais des tests sur ma plateforme de DEV. J’ai l’exemple du plugin WES control qui produit des erreurs sur ma plateforme de test après mise à jour alors qu’aucun changement n’est documenté.

Ayé j’ai pigé :nerd_face: ! Merci pour toutes ces explications !

Bonjour
Si aucun changement est documenté c’est que la mise à jour ne touche pas au code tout simplement. Et oui la doc est liée au code ça permet de garder synchroniser la documentation et le code et de tout avoir à un seul endroit. De plus la mise jour peut aussi juste être une correction d’orthographe par exemple dans ce cas pas de changelog non plus.

Après honnêtement je pense que vous êtes un peu exigent la dessus il n’y a plus de soucis (en officiel) de changelog maintenant et quand je vois les changelog des applications Google sur le playstore je me dis qu’on est plutôt très bon chez jeedom avec ça

1 « J'aime »

Et on comprend, vus les retour ici, pourquoi ils écrivent leur changelog ainsi. Ils donnent une raison sans vraiement en donner une, mais cela a le mérite de rassurer.

Antoine

Moi ça me va bien comme fonctionnement, même si pifou propose une évolution ici qui pourrait contenter tout le monde (pas de maj du plugin si juste modif de doc). Je posais juste la question par curiosité et comprendre la logique technique derrière :wink:

Loïc,

J’ai un exemple, le plug-in WES control.
Une mise à jour c’est présentée il y a plusieurs semaines, par sécurité je l’ai installé en environnement de DEV. J’ai un message d’anomalie toutes les minutes. Rien n’est dans le change log.
J’ai vu sur ici que d’autres utilisateurs avaient le pb. J’ai donc ouvert un ticket pour le signaler.
Une nouvelle mise à jour c’est présentée le 27/09, toujours rien dans le Change Log. Je l’ai installé en DEV, toujours le même problème. Pas de retour du support après cette mise à jour.
Ce plug-in marche de concert avec la version du serveur WES, peut-être faut-il mettre à jour ce serveur aussi ?
Si j’avais des info, je pourrai participer aux tests et aider le développeur.
Le serveur WES chez moi supporte toute mon installation Solaire + Chauffe-eau + Chauffage, c’est important qu’il ne soit pas planté :slight_smile:

Bonjour,
Je ne peux pas te dire pour ce qui ne relève pas de mon périmètre désolé.

Oui, bien sûr. C’était un exemple. Sans change log c’est parfois périlleux pour certains. C’est aussi pour cela que beaucoup demandent d’alimenter le Change Log au moins une phrase afin que l’on mesure les risques.

Je peux comprendre mais pour moi c’est pas possible, le changelog c’est si ya un changement dans le code si pas de changement j’ai pris un temps de malade pour mettre une en tete qui explique ca et ca restera comme ca.

Avec ce genre de demande entre le debut de jeedom et maintenant je mets 2 à 3 fois plus de temps pour la moindre modification, je ne vais pas en plus m’en ajouter pour dire j’ai mis un « s » en plus pour corriger une faute.

Sans compter la maj du au robot qui passe pour la traduction aussi par exemple, si je lui fait rajouter une ligne le lendemain il va passer traduire la ligne qu’il a lui meme ajouté et remettre une ligne pour dire qu’il a traduit la ligne précedente c’est ingerable.

Après si vraiment ca vous gène je peux la faire comme sur le google playstore : bugfix a chaque maj. Je pense qu’a un moment faut arrêter de tirer sur la corde en permanence et voir que la qualité des changelogs et largement suffisante et laisser un peu de mou a l’équipe pour qu’elle s’occupe des vrai probleme.

2 « J'aime »

Je suis surpris de ta réponse. Je ne parle pas de la doc mais de plug-in importants, structurants.
Une modification de code me parait être essentiel à signaler parce que cela a des conséquences chez les utilisateurs. On parle de 35 000 users, à cette échelle c’est normal qu’il y ait des attentes et je crois sincèrement que c’est une des attentes, améliorer la qualité. ça évite des personnes qui s’énerve parce que d’un seul coup ça ne marche plus chez eux après une mise à jour, ça évite des messages au support pour les mêmes problèmes. En connaissance de cause, chacun peut choisir ou pas de faire une mise à jour.
Si je reprends mon cas, je suis dans le vide sidéral ! il y a des bugs connus sur le WES, 2 mises à jour sans aucune info et le bug signalé (ce n’est pas une paille un message toutes les minutes) on ne sait pas ce qu’il en est. Écrire ce que nous devons ou pas faire pour appliquer la mise à jour prend 1 minute.

Je c’est meme pas ce que c’est un WES donc je peux pas parler pour ce plugin.

Tous ce que je peux dire c’est la regle que j’ai :

  • si je touche au code => il y a une ligne dans le changelog
  • si c’est une correction/mise a jour de doc ou une correction de faute d’orthographe dans le plugin => il n’y a rien dans le changelog qui le signal dans son entete

Salut,

Ce n’est pas le sujet du présent post.

Merci d’ouvrir ton propre sujet ou de relancer sur le sujet déjà existant car ce n’est pas cette manière que tu risque d’avoir une réponse.

Je crois que Franck_jeedom et Loic disent la même chose.

Franck_jeedom donne l’exemple d’un plugin dont le code a probablement dû être modifié puisque des messages d’erreur sont apparus après l’installation et pour lequel il n’y a pas eu de changelog. Il ne trouve pas ça normal.

Loic dit que s’il y a modification du code (pas une simple correction orthographique d’un texte) il doit y avoir un changelog.

3 « J'aime »