Bonjour à tous,
Je tourne sur la dernière version stable V4.1.28 en prod, J’essaye au fur et à mesure de passer les plugins Béta et Stable en fonction des compatibilités annoncées avec la 4.2 .
Je pourrais faire un clone en 4.2 Béta avec Proxmox, mais pas le temps de vérifier par moi même, et ce qui suit pourrait intéresser la communauté 
:
Y aurait-il la possibilité de centraliser ici les plugins compatible, en cour d’ évolution vers cette compatibilité et non suivis (ou abandonné 
)
A renseigner par les bêta-testeurs ou développeurs, ( un post par plugin, c’est juste une idée ! )
Merci
Thierry
1 « J'aime »
Bonjour,
Il faut garder à l’esprit que à priori le fonctionnement de base, le cœur des plugins ne sera normalement pas impacté: un plug-in qui fonctionne en 4.1 fonctionnera en 4.2; il peut y avoir des exceptions mais cela restera limité.
L’impact sera éventuellement sur l’interface, page de config et/ou widget, mais là aussi dans la grande majorité des cas cela sera transparent, surtout si les recommandations de dev étaient déjà appliquées.
Bonjour,
J’ajouterai qu’à première vue nul besoin d’un sujet pour centraliser ces informations si les tags sont correctement utilisés ce n’en est que plus simple à suivre même si dans plusieurs sujets différents : #v4_2
1 « J'aime »
ben je trouve que c’est une très bonne idée de centraliser.
a chaque changement majeur de version, c’est la chienli d’aller voir sur tous les tags si compatible ou pas.
L’idéal serait même un plugin qui dit tout ça !
Pour les devs (pour les utilisateurs aussi d’ailleurs) c’est clairement impossible à suivre !
Alors le message qui concerne mon plugin c’est le n°152 sur 328…
Alors qu’un simple clic sur v4_2 te permet de voir tous les sujets en lien avec la v4.2 et le plugin concerné. C’est d’ailleurs tout le principe de fonctionnement de ce forum de ne pas faire de sujets de « centralisation » (hormis les fils d’actualité des plugins sur lesquels seul le dev peut écrire) mais d’utiliser les tags pour une recherche et une lecture bien plus aisées.
1 « J'aime »
C’est déjà centralisé par l’utilisation du tag sur community !
On ne parle pas des tags sur le market 
Suivez le lien que @Salvialf a donné
Et ce n’est pas un changement de version majeur
1 « J'aime »
effectivement, c’est clair en suivant ce lien … ahah !!
J’ai fait un rêve
Les développeurs de plugins tiers mentionnaient dans les fils de discussion dédiés à leurs plugins, la compatibilité (ou non) de leur développement avec le core 4.2 … en ajoutant le tag #v4_2 bien sûr !
1 « J'aime »
Tien, voilà une idée meilleur que la mienne !
Je cloture alors puisque c’est la solution 
?
Thierry
1 « J'aime »
Les développeurs ajoutent les infos de compatibilité directement dans leur plugin. Une ligne du fichier info.JSON sert a ça.
Mais dommage c’est repris que par le market et le 4.2 n’existe pas.
J’ai fait un rêve ou la vie était centralisé et facile, l’info placée une fois et recopier directement la ou il faut y compris sur community.
Après les plugin s OK en 4 doivent l’être en 4.2, y a pas de changements ‹ imposé › les nouveauté sont transparentes
Bonjour
Utilisateur lambda, je sais que je dois m’informer sur les plugins que j’utilise en :
- Lisant la doc
- Regardant le changelog
- Consultant les fils de discussion dédiés aux plugins
Par contre, j’ignore le fichier info.JSON
Je constate que nous avons une approche différente sur l’information relatives aux plugins tiers.
Pour ma part, je trouve logique que les développeurs assurent directement la communication sur leurs plugins avec leurs utilisateurs en utilisant Community, y compris dans le cas d’évolution liée au Core
Je sais également que certains utilisateurs ne font pas l’effort de lire la documentation ou les contributions sur Community, avant d’évoquer leurs problèmes… mais c’est un autre sujet
Merci pour l’information suivante :
En espérant que cela soit le cas pour tous les plugins tiers
En tant que dev, si je remplis mon info.json voilà ce que ca donne pour les utilisateurs :
Ca c’est sur le market. Donc si il faut renseigner de la compatibilité sur le forum, il faut que Jeedom SAS reprenne se principe et l’automatise depuis sa meme source, sinon c’est encore une perte de temps.
Pour la compatibilité 4.2 des plugins tiers, ben si c’est pas le cas, faudra pas s’en prendre aux tiers mais à Jeedom SAS, car c’est ce qu’ils communiquent. On a 0 demande spécifique à l’arrivée de la 4.2.
Par contre personnellement je pense que je vais retirer la compat avec la v3 quand la v4.2 sortira…
De mémoire il y avait un code à mettre dans un scénario bloc code pour voir les plugins compatibles v4.
Salut @lunarok,
Ce n’est pas tout a fait vrai, effectivement la grande majorité des nouveautés de cette V4.2 est sans incidence et est de toute façon largement documentée à destination des développeurs :
https://doc.jeedom.com/fr_FR/dev/core4.2
Il n’en reste pas moins qu’une communication a été faite à plusieurs niveaux concernant la nouvelle politique de sécurité,
- Dans le changelog : https://doc.jeedom.com/fr_FR/core/4.2/changelog#4.2%20%3A%20Sécurité
- Dans une communication faite aux devs : Securité : changement de politique sur l’accès aux fichiers - Salon des Développeurs - Communauté Jeedom
- Et dans un article du blog : Introduction Jeedom 4.2 : la sécurité – Jeedom – Le Blog
Il faut donc au moins s’assurer que ses plugins soient conformes à cette politique de sécurité pour la sortie de la 4.2.
2 « J'aime »
@Salvialf je n’avais pas fait attention à ce change :
- L’usage de
showAlertchange :$('#div_alert').showAlert({devient$.fn.showAlert({. Pas de changement pour l’appel depuis une modale. Non supporté sur Core pré 4.2.
J’ai pourtant des anciens fonctionnements qui sont fonctionnels en 4.2… ça fait des alertes qui disparaissent (sauf si rouge) en bas à droite… mais ça fonctionne tout de même !
Comment gérer si ce n’est pas supporté avant 4.2 ? Tu aurais un exemple ?
C’est deprecated mais pas obsolete.
Donc pour moi on peut l’utiliser encore et on doit même tant qu’on supporte un jeedom < 4.2 (même un 4.1 donc)
Faudra penser à changer plus tard, en v5?
Edit: j’avais déjà donné cette opinion mais ce qu’il nous manque nous dev tiers c’est d’avoir une vue sur les versions utilisée (En %)
Donc de savoir qu’il reste 25%, 10% ou 1% de v3 par exemple et pareil pour les autres.
On n’a pas besoin de tout mais par exemple les v3, les v4&v41, les v42 etc, chaque fois qui y a des changements potentiellement impactant.
Sinon c’est difficile de savoir ce qu’on doit supporter ou pas et quand on peut faire les changements marquer comme « deprecated » en mettant à jour notre version minimim du core (dans le info.json)
2 « J'aime »
Comme je l’écrivais précédemment « nous avons une approche différente »…
A la lecture de ce qui a été écrit sur cette future V4.2 du Core, ajouter sur le market un nouveau « marqueur » de compatibilité semble disproportionné.
Et dans la pratique, je ne vais pas sur le market, sauf avant l’achat d’un plugin.
Cette 4.2 nécessite un peu de communication et de participation des développeurs tiers et des utilisateurs… ce qui est pour moi un indicateur sur l’implication d’un développeur.
Ce qui est clair, c’est que je ne reprocherai pas à Jeedom SAS toute l’information qu’elle partage
Mais on ne se convaincra pas, tellement nos approches sont différentes
1 « J'aime »
Pour l’instant c surtout pour le core mais on le signale quand même. Car en effet avant 4.2 ça marchera pas. Pour l’instant je dirai touche à rien … quand la 4.2 sera stable les 4.0 et 4.1 n’existeront plus sur le git donc en pourra commencer à changer mais pas urgent et sûrement encore supporté en 4.3
1 « J'aime »
Pas de quoi. On essaye de signaler même en avance. Comme utils.js qui en 4.2 est isolé dans un namespace mais on a gardé les anciennes fonctions en alias pour rien casser. Dans qql versions on pourra prévenir sur un futur obsolète. On essaye vraiment d’optimiser le code et d’avancer sans rien casser et je pense qu’il vaut mieux prévenir qql versions avant plutôt que l’inverse 
3 « J'aime »
Je n’ai pas de problème avec le changement, tant qu’il est planifié, communiqué et qu’on a un exemple/moyen de remplacement documenté aussi (je sais c’est du boulot, mais pour avancer ca demande de l’explication, tout changement justifié et expliqué passe mieux !)
2 « J'aime »