Bonjour,
Teste et fais nous un retour 
Bonjour,
J’aurais pas mieux dit que Mips dans le post que Madcow a remonté ici.
ça me semble prématuré puisque Jeedom vient tout juste de passer sur la v11 mais si tu n’utilises pas de plugin trop exotique ça se tente …
Quand je dis « trop exotique » ce n’est pas un reproche évidemment mais ceux qui ont pas mal de dépendances risque de poser plus de problème que ceux qui n’en on pas à installer.
Déjà faut l’alpha
Vous vous êtes donné le mot ce soir?
Même pas 
Ca doit etre l’effet vacances.
Bon on va attendre alors.
on aura toujours une version de retard j’ai l’impression
Dans un environnement de prod oui c’est pratiquement toujours le cas (et ce n’est pas valable que pour jeedom)
1 « J'aime »
Bonjour,
Dans un environnement de prod oui c’est pratiquement toujours le cas (et ce n’est pas valable que pour jeedom)
Sur ce point, je ne suis pas d’accord.
On évite en général d’avoir trop de versions en retard, de cumuler la dette technique, et de garder des failles connues.
Sinon, le pentest (test de sécurité) du produit ne passe pas, et les gros clients passent à un autre produit ou demande une mise à jour en demandant une ristourne.
Du moins, pour le produit sur lequel je travaille (logiciel de GMAO), c’est comme cela que cela se passe.
De plus, Debian n’est pas réputé pour mettre à jour rapidement leurs packages. Ce qui allonge encore le retard d’Apache et PHP.
La version de PHP sous Bullseye 11 est v7.4.
Sous Bookworm 12, c’est v8.2.
On peut dire par contre que Jeedom fait ce qu’il peut avec les moyens en place, et évite de bousculer les développeurs de plugin.
La mise à jour de Node, par exemple, n’a semble-t-il pas été évident à mettre en place pour les plugins.
Je souhaite bon courage aux dev Jeedom pour avancer sur leur chantier.
Edit : Jeedom fait en sorte d’enlever jQuery, ce qui est déjà un gros boulot en lui-même.
Je met des petites images ci-dessous pour le lifecycle :
Debian :
PHP :
Alors je reformule,
je ne parlais pas d’un point de vue du développement, mais d’un point de vue utilisateur qui n’est pas censé être geek.
Un utilisateur final lambda (une personne mais surtout une entreprise) ne va pas appliquer les maj d’un core a chaque migration disponible, c’est trop de risques de plantage et de blocage du fonctionnement économique. Il va de soit que les maj securitaires sont essentielles et c’est pourquoi les versions LTS sont à privilégiés pour les utilisateurs finaux qui ont besoin d’une stabilité dans le temps.
Bien entendu, quand une migration est possible et que tout les feux sont verts, que les tests ont été fait
sur un envirronement de test avec les données de l’utilisateur final, on lui programme une migration.
Donc oui la plupart du temps l’utilisateur final n’a le plus souvent pas les dernières versions (php, apache, kernel etc etc). Même si les dev font le max pour faire le necessaire sur leur soft.
Et pour certaines migrations se pose la question matérielle. Si je prends un exemple (je vais dire un gros mot pour certains😋): une migration Windows est parfois impossible sans upgrader la machine (Ram, Espace disque etc).