Bonjour,
je propose de commencer par créer des fonctions alias dans un premier temps pour qu’on puisse utiliser les fonctions avec « daemon » écrit correctement. Puis, quand on passera en V5 (?) de passer sur les fonctions écrites correctement uniquement.
Vous en pensez quoi ? J’espère ne pas jeter une pierre dans la mare…
A+
Michel
Hello,
De mon point de vu ce n’est pas une mauvaise idée, pourquoi ne pas aller un cran plus loin et attendre que les plugins mettent toutes les fonctions en rapport avec leur daemon dans une classe %plugin_name%Daemon ?
Bad
Salut,
Je pense que personne ne sera pas d’accord sur le principe, j’aimerais aussi que ça soit en ordre.
Mais il faut voir le problème dans son ensemble et il faut bien être conscient que c’est 2 migrations et pas une.
Il faut d’abord que chaque plugin appelle l’alias ou la class dans chacune des fonctions au moins pour une phase de transition.
Parallèlement le core doit tester l’existence des deux fonctions et appeler celle qui existe.
Après un certain temps et des centaines de plugins à mettre à jour, lorsque suffisamment d’utilisateur sont sur la dernière version du core on peut commencer la deuxième migration:
Chaque plugin va augmenter la version minimum requise du core et supprimer l’ancienne fonction.
Et dans seulement encore quelques versions le core peut arrêter de tester les deux méthodes.
Et là on va avoir des centaines de posts sur community demandant « bug mon démon démarre pas »
Bref c’est un coût énorme, gigantesque. Et la valeur ajoutée c’est quoi? Quelques devs (moi inclus) qui dorment mieux la nuit. Aucun bénéfice pour l’utilisateur final.
Tout ca pour inverser 2 lettres.
Voilà je ne veux pas paraître réfractaire aux changements mais il faut peser le pour et le contre d’autant plus dans un contexte où les ressources sont limitées (elles le sont toujours);
il y a certainement d’autres points pouvant être améliorés qui apportent plus de valeur.
ça, c’est le problème de n’avoir qu’une seule branche. On ne devrait pas casser la compatibilité tant que l’on reste sur une v4.x … Il faudrait mettre ces modifications sur une branche pour une future v5, et l’annoncer clairement, la v5 ne sera pas compatible avec la v4. Ainsi les plugins pourront recevoir un tag v5 lorsqu’ils deviendront compatibles, ils pourront aussi conserver une autre branche v4 pour ceux frileux qui ne veulent pas faire la migration et ainsi de suite.
Mais pour cela, il faudrait maintenir 2 branches 
Je me suis fait cette remarque suite aux évolutions sur la v4.4 côté jquery, qui ne sont manifestement pas compatibles avec l’existant mais que pourtant on veut faire passer sur la v4… et je suppose que cela va entraîner une double migration aussi.
Salut,
Je comprends pas trop cette remarque ?!? 
L’alpha est totalement compatible avec les plugins existants, le contraire n’est pas pour demain. Il me semble bien que ça a déjà été expliqué sur le sujet relatif à l’alpha d’ailleurs… Bref aucun feu à allumer sans raison, la compatibilité avec l’existant ne sera jamais cassée pour faire passer je-ne-sais-quoi malgré tout, ça n’aurait aucun sens.
Il y a (avait) deux branches (v3/v4), et on a vu ce que ça a donné, donc pas convaincu que c’est la solution de faire une 3ème.
Le fait qu’on ne doit surtout pas mettre à jour nos plugins avant v4.6 pour ne pas casser la compatibilité justement. Et donc le core a 2 versions mineures d’avance sur les plugins, si j’ai bien compris ce principe de la double migration.
ça a duré combien de temps ? Je veux dire, un développement continu sur les 2 branches ? La v3 reste là je suppose uniquement pour recevoir des patchs de sécurité critique, je ne pense pas qu’on ai continué à ajouter de nouvelles fonctionnalités sur la v3 après la sortie de la v4 (?)
Y’a pas de double migration je ne comprend mème pas ce que tu veux dire.
Chaque version du Core même mineure apporte des nouvelles fonctions (heureusement…), que les plugins peuvent utiliser (ou pas). Mais forcément ces fonctions ne sont pas sur les versions précédentes du Core, donc si un plugin les utilise il doit spécifier le require (minimal core version) en fonction, c’est normal. Tu peu tout a fais faire un plugin basé sur les fonctions du core 4.4, faudra juste qu’il ne s’installe pas sur un pré-4.4. Logique …
c’est moi qui ait parlé de « double migration » (et donc pas dans le contexte jquery pcq là je ne sais plus de quoi on parle)
et je disais ca dans l’idée que les plugins assurent la rétro-compatibilité avec les anciennes versions du core;
comme tu dis, chacun est libre de ne pas gérer ca, c’est vrai.
C’est une double migration dans le sens où on migre d’abords le core - v4.4 - qui sortira quand, d’ailleurs? - puis on pourra ensuite travailler sur les plugins - v4.5 donc, pas avant - puis en v4.6 ça sera clean, double migration terminée.
Je suis conscient des avantages de cette méthode, déjà, 1 seule branche stable à maintenir évidemment, et puis du point de vue utilisateur on n’a pas forcément envie de sauter de version tous les 6 mois avec tous les problèmes que ça peut engendrer. A titre personnel j’ai eu du mal à passer à la v4.
Par contre je n’avais pas encore réalisé les inconvénients de cette méthode, avant que tu pousse tes évolutions sur Vanilla / jQuery et que je réalise que je ne pourrais pas les appliquer sur mon plugin avant longtemps. Parce que sur nos plugins non plus on ne peut pas maintenir plusieurs branches je suppose, je me tâte à publier une nouvelle version du plugin spécifique v4.4 sur un autre repo pour ne pas perdre ceux des versions précédentes…
C’est toi qui tient absolument à adapter un plugin pour la 4.4 alors qu’elle est encore qu’en alpha …
Après le minimal 4.4 c’est surtout si tu utilise des racourcis de domUtils ou des libs incorporées en 4.4 → https://doc.jeedom.com/fr_FR/dev/corejs/index
Du pur js (des queryselector, changer de class, addeventlistener etc) çà marche en v3 …
Pour relancer le débat, faire un alias pour les fonctions daemon_* vers deamon_* permettrait aux gens comme moi que ça dérange d’écrire quelque chose de faux, de pouvoir écrire juste et ça marcherait quand même, même si c’est écrit juste.
Ça ne mangerait pas de pain, les fonctions avec l’erreur de typologie peuvent rester pour la compatibilité…
Tu a fait une recherche sur tout le code du Core ?
Certes c’est faisable, comme tout, mais y’en a partout …
Pour un alias ? Il suffit que la fonction sans erreur de typologie ne soit pas définie et ça fonctionnera, me semble-t-il.
On ne parle pas que d’une ou de fonctions… et pas que de php …
https://github.com/jeedom/core/search?p=1&q=deamon
Et encore, y’a pas tout …
rôoh la vache…
je reste sans voix
moi qui pensais que ce serait « juste un alias » mais en fait la faute n’est pas que là… elle est aussi dans les noms de fichier, les… partout… !!!
bon je vais devoir vivre avec ça alors.
Ou alors on fait un gros grep et on tire un trait sur le retro-compatibilité 
?
Non c’est bon, j’abandonne, c’était une blague
Ben oui, c’est bien de vérifier avant… çà ne mange pas de pain hein ? 
Faudra le faire un jour, mais la 4.4 n’est peu être pas la plus indiquée pour çà.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.