Bonjour,
Pour information la version 3.3.X de jeedom sortira mardi 12 Mars 2019 en stable
Rectification de date passage du mardi 5 au 12
1 « J'aime »
Merci pour l’info (et le travail d’assistance sur le forum, respect pour ta patience !!).
Bon courage pour la gestion de la migration.
Au cas ou voici le ChangeLog :
- Possibilité de supprimer une variable.
- Ajout d’un affichage 3D (beta)
- Refonte du système de backup cloud (backup incrémental et chiffré).
- Ajout d’un système de prise de note intégré (dans Analyse -> Note).
- Ajout de la notion de tag sur les équipements (se trouve dans la configuration avancée de l’équipement).
- Ajout d’un système d’historique sur la suppression des commandes, équipements, objets, vue, design, design 3d, scénario et utilisateur.
- Ajout de l’action jeedom_reboot pour lancer un redémarrage de Jeedom.
- Ajout d’option dans la fenêtre de génération de cron.
- Un message est maintenant ajouté si une expression invalide est trouvée lors de l’exécution d’un scénario.
- Ajout d’une commande dans les scénarios : value(commande) permet d’avoir la valeur d’une commande si elle n’est pas donnée automatiquement par jeedom (cas lors du stockage du nom de la commande dans une variable).
- Ajout d’un bouton pour rafraichir les messages du centre message.
- Ajout dans la configuration d’action sur valeur d’une commande un bouton pour chercher une action interne (scénario, pause…).
- Ajout d’un action « Remise à zero des SI » sur les scénarios
- Possibilité d’ajouter des images en fond sur les vues
- Possibilité d’ajouter des images en fond sur les objets
- L’information de mise à jour disponible est maintenant masquée aux utilisateurs non admin
- Amélioration du support des () dans le calcul d’expressions
- Possibilité d’éditer les scénarios en mode text/json
- Ajout sur la page santé d’une vérification de l’espace libre pour le tmp Jeedom
- Possibilitée d’ajouter des options dans les rapports
- Ajout d’un heartbeat par plugin et de redemarrage automatique de démon en cas de soucis
- Ajout des listeners sur la page de moteur de tâche
- Optimisations
- Possibilité de consulter les logs en version mobile (wepapp)
- Ajout d’une action tag dans les scénarios (voir documentation)
- Possibilité d’avoir une vue en pleine écran en ajoutant « &fullscreen=1 » dans l’url
- Ajout de lastCommunication dans les scénarios (pour avoir la date de derniere communication d’un équipement)
- Mise à jour en temps réel des graphiques (simple, pas ceux calculé ou les timelines)
- Possibilité de supprimer un élément à partir de la configuration du design
- Possibilité d’avoir un rapport sur le niveau de batterie (rapport équipement)
- Les widgets scénarios sont maintenant affiché par défaut sur le dashboard
- Changement du pas des widgets par horizontal 25 à 40, vertical 5 à 20 et marge 1 à 4 (vous pouvez remettre les anciennes valeurs dans la configuration de jeedom, onglet widget)
- Possibilité de mettre une icone sur les sénarios
- Affichage des widgets mobile en une seule colonne
- Ajout de la gestion des démons sur le moteur de tache
- Ajout de la fonction color_gradient dans les scénarios
5 jours pour se mettre en conformité du coup, c’est pas un peu juste ?
On est en période de vacances scolaires, la semaine prochaine encore pour 1/3 des académies. Donc potentiellement des users avec pleins de temps pour migrer mais si un dev est sur les pistes et n’a pas le temps de se mettre en conformité cette semaine ?
Ceux qui ne sont pas présents ici de facon régulière n’auront rien vu arriver. Même en étant fréquemment ici, on a souvent la remarque que ce qui est dans la beta peut partir du jour au lendemain, rien n’est fixé.
Exemple les modifs graphiques, vu les modifs et que rien n’était figé (vu les retours ici un peu normal), j’ai touché à aucun widget, pourtant j’en ai un paquet qui sont massacrés avec les changements.
Et jeudi je pars à l’étranger, donc je fais partit de ceux qui ne seront pas présent pour la sortie et du coup tant pis, pas de choix, ca va gueuler que les widgets sont moches, ils attendront. Pareil si ca lève des bugs sur mes plugins, ils attendront.
Tu as la version beta de disponible depuis un moment pour tester… De plus la 3.3 ne casse pas grand chose quand même :
- les widgets => juste des options a changer dans le paramétrage de jeedom pour revenir comme avant
- le reste c’est rétrocompatible
Après on peut pas contenter tout le monde quoiqu’on fasse quoiqu’on dise ca n’ira pas a quelqu’un et un moment faut avancer.
J’ai l’impression de pas me faire comprendre. Je vais réessayer.
Je parle pas de mon cas pour les informations au dev, mais globalement. Tous les devs ne sont pas ici, tous les devs ne sont pas en beta et vont attendre une annonce pour s’en préoccuper. C’est ce que j’avais indiqué pour le heartbeat que ca mériterait une info par newsletter dev. C’est pas toi qui la fait je sais, mais quand même elle devrait être faite avec les points qui sont à savoir pour les devs. Et pas avec un délai de 5 jours.
Le changelog est global, aucune incidence pour un dev que de nouvelles fonctions soient dispo dans les scénarios. Par contre qu’une classe soit renommée ca oui. Il faut une info ciblée pour les devs. Et là c’est trop tard, comme dit vacances + 5 jours, ca va grogner. Au passage des devs vont encore abandonné, dépités par les délais pour se mettre à jour.
La beta est dispo depuis des mois, ok, sauf qu’elle évolue quand même.
La classe Objet renommée par exemple, mika qui est présent ici et utilise la beta l’a vu oui. Mais quid d’autres devs moins présents ? Ils vont découvrir lundi que leur plugin ne marche plus.
Les widgets c’est pas ceux de mon jeedom qui me posent soucis, c’est ceux intégrés à mes plugins. Vigilance Météo c’est un massacre les changements récents, et ca vu qu’on a aucune garantie que les changements graphiques restaient, j’ai rien fait pour pas perdre mon temps.
Lundi pareil, les users vont avoir des widgets pourris juste en upgradant le core et sans que les modifs de configuration marchent.
Le heartbeat aussi au milieu de la liste mérite d’être mis en avant pour un dev. Les listeners sur la page de moteur des taches.
La newsletter tu avais dit que c’était pas toi qui t’en occupait, donc ca ne t’impacte pas directement. Par contre le délai est vraiment trop court sans parler des vacances.
Tu as l’habitude des gros SI, clairement un PM me présente ca en CAB, je met un veto car délai de prévenance trop court.
Ok ben moi j’abandonne je fais l’alpha et c’est tout me demandez plus rien et je vous demandez rien pour la beta/stable je laisse les autres voir tout comme les communications.
Je rejoins @lunarok sur le besoin d’une newsletter d’inforamation special dev.
Actuelement si on ne cherche pas les problemes, ils seront rencontrée par les utilisateurs et qui vont certainement vous donnée du boulot avec des tickets de support.
La beta est certe accesible au devellopeur mais on n’a pas tous la possibilité d’avoir plusieur machine, et je galere vraiment avec ca.
Sur le fond je vous rejoins, sur le fait que ce n’est pas aux utilisateurs de remonter les problèmes aux développeurs.
Malgré tout j’avoue être un peu perplexe…
Jeedom a mis en place le forum partenaires justement pour regrouper les beta-testeurs et les développeurs de plugins.
Quand on développe des plugins, pour moi on s’engage à les suivre et à anticiper avec les betas les problèmes qui pourraient survenir pour les corriger avant la stable justement. Ce qui sous-entend en effet de se faire un Pi à 30€ pour tester en beta ses plugins.
Et quand je vois le peu de retours sur ce forum partenaires, je suis également surpris. On dirait que tout le monde attends la stable pour corriger ses trucs dans son coin. En râlant au passage sur les changements, pourtant présent depuis des mois en beta, alors qu’on peu en discuter ici bien avant.
Ce qui n’engage que moi …
Bah dit moi ou sur partenaire tu as clairement les impactes a chaque beta.
Moi je les decouvre par moi meme.
Et il n’y a aucune obligation d’etre sur la beta.
Tu dis peut de retour sur se site c’est peut etre un signe que cela ne fonctionne pas.
Perso çà ne me gène pas plus que çà. J’installe la beta, je regarde le comportement de mes plugins, si çà foire je corrige et si je comprends pas, je regarde les commits et j’en parle ici.
Non et c’est normal, comme je le disais c’est la responsabilité de chacun en tant que développeur. Quand on propose un plugin, on s’engage vis à vis des utilisateurs.
Et tu propose quoi ?
Je suis sur des programmes beta et alpha de solutions bien plus complexe que Jeedom depuis une 20aine d’années pour certains. Ce qui marche le mieux, c’est justement une communauté comme celle-ci où on peux discuter de tout çà avant que çà sorte. Et ceux qui ne participent pas attendent la finale et sont à la bourre, c’est le jeu.
Je n’ai rien contre personne hein. Surtout toi, tu est visiblement sur la beta, tu a vue les soucis de la class object, tu en a parlé. Right.
Bonjour, au vu des messages voici ce qui sera fait par l’équipe Jeedom a partir d’aujourd’hui :
1 > Verrouillage Beta (uniquement BugFix peuvent etre commit).
2 > Envoi de la ChangeLog sur partenaire et via newsletter avec les différentes infos de changement de code dans les plugins (si il y en a)
3 > Collage de la Date de Sortie entre 2 et 3 semaines selon modification a faire sur des plugins.
4 > Création de l’article public pour la sortie de la nouvelle version du core.
5 > Sortie de la nouvelle version.
Après c’est aux développeurs de suivre partenaire et les newsletters.
Je tiens a dire que j’ajoute tout les développeurs sur partenaire toute les semaines. donc si a la suite de cette nouvelle mise en place de temp et information pour les dev.
Et si leurs plugins ne sont pas fonctionnel avec le nouveau core Stable à sa sortie ils seront mis en obsolete.
Nous allons donc décaler la mise en Prod de la Beta actuel pour que tout le monde puisse faire les changements. et une newsletter partira Aujourd’hui.
Décalage de la Stable a Mardi 12 Mars 2019
Merci.
1 « J'aime »
Super merci a tous,
On voit que les équipes jeedom sont toujours a l’écoute de la communauté et cela fait plaisir.
1 « J'aime »
Merci.
Malgré tout 2 remarques quitte à passer pour une plaie :
- suivre partenaire pour entendre « c’est que de la beta pas sur que ca reste » ne motive pas à réagir de suite aux changements, donc y a que la newsletter qui concentre bien les infos utiles pour un dev
- le ton de la phrase sur les plugins qui ne seraient pas fonctionnel avec les mots gras penche sévèrement pour de la menace, c’est déplacé. 2 semaines pour réagir ca reste que dalle. le mieux seraient d’avoir une notion de version validée comme wordpress par exemple qui permet aux users de savoir que leurs plugins sont rapportés ok avec les nouvelles versions.
Tu a le droit de t’exprimer 
-
“c’est que de la beta pas sur que ca reste” : car on nous reproche très souvent de pas écouté tout le monde et donc ben on a parfois des rollbacks.
-
pour ce qu’il y a comme modification 2 semaines pour cette version c’est pas trop déconnant a savoir que c’est pas sur tout les plugins qu’il y a ce type de souci. (widget). a savoir que on peut tout a fait donner 1 mois si on voit qu’il y a beaucoup de modification. Tu dit le ton de la menace, ce n’est pas vraiment de la menace, mais on a aussi le droit d’imposer des choses. on est pas non plus des méchants et si on nous dit attention la on va avoir du mal on sort la Stable plus tard ! et si le dev a du mal a tout faire on va pas coupé son plugin du jour au lendemain il reçoit un mail etc… et il y a partenaire pour l’aide.
Pour ta dernière phrase, on y pense mais on ne sait pas vraiment comment faire etc… mais on prend l’idée !
En fait ce qu’il manque peu-être c’est une véritable étape RC (Release Candidate).
- Alpha : étude et réalisation des nouveautés, dédiée au développeurs du core.
- Beta : Utilisable, retour sur les bugs et les nouveautés par les beta-testeurs. Donc discussions et rien de figé.
- RC : featured fixed, UI fixed ! A priori la future stable sauf bug bloquant.
Donc en Beta çà peux bouger en fonction des retours de beta-testeurs.
En RC, çà ne bougera plus donc aux dev de plugins de s’adapter. Et en fonction des retours, des éventuels bugs et de leur gravité (normalement déjà vue en Beta), on donne un time-frame pour la Finale. Et on ouvre les beta public avec la RC pour élargir les retour sur d’éventuels bugs non vues. Mais absolument aucun changement de fonctionnalité / UI.
C’est aussi en RC que sont adaptées les docs, les articles de com sur la sortie etc, voir un début de com sur des Tech Preview pour faire du teasing.
C’est comme çà que fonctionnent les grands éditeurs de logiciels dans lesquels je suis en beta. En tout cas sur les versions majeures, les versions mineures n’ont pas de RC mais seulement du bugfix. Les discussions en cours sont donc intégrées si nécessaire dans la future version majeure.
2 « J'aime »
Bonjour,
Du coup, comment fait on du côté dev pour gérer une version du plugin post 3.3.X et une version pour la 3.3.X ?
Merci