Comme @ylq je cherche à mettre à jour mon core afin de (j’espère) résoudre le bug de l’historique du 01/01/2026.
J’etais bloqué en 4.4.12, après modification de la branche dans la configuration jeedom me propose de basculer en 4.5 2. Cependant je suis encore sur un rpi3b+ en debian 10. Il me semble qu’il n’est pas recommandé (voire possible) de faire tourner jeedom 4.5 sur une telle configuration, est-ce exact ? Dans ce cas, comment basculer sur la 4.4.20, car l’interface ne me le propose pas. J’ai tenté de spécifier ce tag précis dans la configuration, mais j’ai alors une erreur 404 dans l’interface de mise à jour.
Merci à tous, et désolé si la question est évidente, je n’ai pas trouvé cette réponse dans les forums. Promis j’envisage de basculer jeedom sur mon Pi5, mais j’aimerais ne pas le faire dans l’urgence.
à court terme de patcher les deux fichiers à la main (pb d’historique et pb de vérification de la date)
à moyen terme de réfléchir à un upgrade de ta conf (quels plugins tu utilise, passer sur une version de debian maintenue, est ce que le repb3b+ est suffisant …) sans précipitation.
Merci beaucoup pour vos réponses. Je pensais que les correctifs avaient été réintégrés dans la branche 4.4 depuis le temps. Je trouve que c’est dommage mais bon, je vais essayer de corriger par moi-même.
D’ailleurs, est-ce que quelqu’un sait pourquoi cela n’est pas le cas ? (sans polémiquer, juste pour comprendre la logique). Il me semble que, au moins pour l’un d’entre eux, c’était pour le support du rpi1, donc plutôt obsolète non ?
(à moyen-terme je vais passer sur un rpi5 + Debian 12 + Jeedom 5.2 en espérant ne pas perdre trop de plugins au passage)
D’après ce que j’ai compris c’est l’effet de bord d’une tentative de simplification du nombre de branches dans le dev. En gros la stable aujourd’hui c’est la 4.5 mais il n’y a plus de branches spécifiques a une version comme pour le passé.
C’est plus simple pour faire évoluer le produit mais du coup oui on ne peut plus patcher simplement les vieilles versions
Juste pour clarifier, il n’y a jamais eu de branche spécifique à une version. Inimaginable de devoir maintenir à part chaque versions de Jeedom, le souci est que chacun ne voit que sa version mais si patch 4.4.20 alors il faut aussi toutes les précédentes ça commence à faire ! et les 4.3.x, 4.2.x, etc. voire V3 aussi c’est juste impossible !
La seule branche spécifique à une version Jeedom ever était la v4-stable mais elle apportait de profonds changements.
En effet, supporter la maintenance de plusieures branches d’un même produit a un coût important ; même les éditeurs de produits payants sous licences le font avec beaucoup de parcimonie, et en général pour les versions anciennes vous font payer des « extensions de licence » à des prix exhorbitants.
Le support de jeedom pour un produit opensource gratuit est exemplaire.
Evidemment je comprends que les personnes qui n’ont pas ou peu de compétences techniques soient un peu démunies pour faire des montées de version de l’os debian, sur un hardware démodé (type pi 3b+) qui a du mal à compiler les dépendances des plugins mis à jour.
C’est aussi un peu la rançon du succès de jeedom qui en 10 ans a conquis de nombreux utilisateurs ; Loic citait qu’en ce début d’année une petite moitié du parc est en 4.5.x, ce qui veut dire que l’autre moitié ne l’est pas pour tout un tas de raisons
Merci pour vos réponses, je comprends que la version 4.4 n’est plus supportée (au sens plus de correctifs), ce qui m’incite d’autant plus à migrer.
Je pensais que 4.4 était une branche avec différents tags (4.19, 4.20) et que la 4.5 était une autre branche avec ses propres tags. Sur le produit que je développe nous reportons sur la dernière branche les correctifs de la branche en cours, donc dans cette logique le ptach aurait été seulement sur une 4.4.x. Mais c’est vrai que cela a un coût non négligeable, surtout quand les branches commencent à diverger, et notamment pour tester les non-régressions. Et chaque produit adopte sa propre stratégie en fonction de ses moyens.
En attendant une solution plus pérenne je vais faire les modifs à la main, cela n’a pas l’air très difficile.
Bonjour
Comme nouveau ici, je ne comprend pas tout.
J’ai vu passer des posts où des utilisateurs se faisait engueuler parce qu’ils avaient fait des mises à jour sans lire le change log.
Et maintenant, il y a un forçage inconditionnel vers 4.5.x.
Il n’y a pas moyen de pousser le correctif de bug scénario+historique sur 4.4.20?
Je ne dit pas cela pour moi, je suis à jour et je saurais modifier deux lignes dans un fichier.
Je le dit pour le moi du futur avec sa 4.5.x obsolète mais qui fonctionne très bien comme cela et qui aurait un peu les boules le jour du bug « 2026 », et qui ne sera plus capable d’aller modifier les fichiers (et pour tout ceux qui ne savent/veulent pas le faire).
De mon point de vue il suffit de relire la question pour y répondre en fait… Si un bug était prévisible à l’avance bah y’aurait plus de bug finalement ! De là à en conclure que c’est volontaire pour forcer un passage en 4.5… Wouah quand même, même si arrivé en 2026 je devrais être blasé par une telle théorie du complot. Dans quel but ce serait ? Y’a quoi de si fou en 4.5 qui mériterait d’être si machiavélique ? L’intégralité du code est open source et librement consultable.
Je ne parle pas de complot.
Je me mets juste dans la peau d’un utilisateur normal qui a une vielle version (ce que je ne suis pas du tout aujourd’hui mais qui le deviendra demain).
Oui c’est un peu chiant mais il faut régulièrement (on va dire une fois par an ?) voir si des upgrades sont à réaliser que ce soit au niveau de la version de jeedom, de debian ou du hardware.
Chaque update est une marche, il vaut mieux en franchir une petite régulièrement que devoir les monter 3 par 3 en catastrophe faute d’avoir anticipé.
Rien n’empêche de mettre à jour Jeedom dans l’absolu. Au pire des mises à jour système, justement pas mal d’outils ont été mis à disposition pour se faire que ce soit pour les boxes officielles ou DIY X64. Il est tout à fait recommandé de suivre les évolutions dans le domaine de la domotique
Il y a déjà eu ce débat dans d’autres posts: il n’y a pas de branche 4.4.x, le versionning est sur 4. donc le correctif du bug sur la 4.4.20 c’est la 4.5.2; ce n’est pas un forçage inconditionnel, c’est juste la prochaine version.
On peut tout à fait comprendre que l’équipe ne maintienne pas des patchs sur la 4.4 et puis aussi la 4.3, ni des patchs de sécurité sur la 4.1 ; c’est pas une équipe de la taille de microsoft pour maintenir windows
c’est vrai que ce bug de date est chiant parce qu’il oblige à monter de version (en urgence) pour des gens qui seraient bien resté sur une version ancienne de jeedom qui convenait bien à leur usage ; malheureusement les bugs c’est comme ça
Je sens que le post est en train de partir en vrille. Je voulais juste comprendre le fonctionnement du produit, pas lancer une polémique sur la stratégie de gestion des branches. Plutôt que de discuter à l’infini, peut-être qu’un de nous pourrait faire une PR sur la 4.4.20 qui corrigerait ces 2 problèmes majeurs, surtout s’ils affectent 50% de la communauté . Est-ce qu’elle serait acceptée si j’en fais une ?
Ceci dit, il me reste 2 questions : (pour rappel je suis encore sur un rpi3, donc je ne peux pas migrer sur la 5.2, enfin il me semble) :
Je ne comprends toujours pas s’il est possible de passer en 4.20 avant de modifier les fichiers manuellement ?
Rappel : Je suis en 4.4.12.
Si je mets « stable » dans la combo box de la configuration, l’interface ne me propose que de passer en 5.4.2.
Et si je mets « 4.4.20 » dans la configuration, j’ai « 404: Not Found » comme dernière version dans le centre de mises à jour. Que va-t-il se passer si je fais une mise à jour quand-même ? Vais-je passer en 4.4.20 ?
Sur une box officielle les mises à jour système et Jeedom se déroulent en 3 clics maximum. Sur du « Do It Yourself » la réponse est dans le titre : tu fais toi même.
. Est-ce qu’elle serait acceptée si j’en fais une ?