Un bêta‑testeur est un utilisateur qui teste les versions du logiciel avant qu’elles soient diffusées à l’ensemble des utilisateurs. Le bêta-testing permet de remonter des erreurs qui pourraient apparaitre lors de la phase de développement (bug fonctionnel ou souci d’interface par exemple). C’est une importante source d’amélioration pour le projet, qui permet d’apporter des idées fraîches et de tester les nouveautés en conditions réelles.
Bien que les développeurs prennent un maximum de précautions, les versions en cours de développement sont susceptibles d’inclure des bugs pouvant rendre un plugin ou le core totalement inopérants. De la même manière, les fonctionnalités en cours de développement peuvent être reportées, voire abandonnées en fonction des circonstances. Il faut donc être plutôt à l’aise avec les procédures de sauvegarde/restauration de Jeedom avant de se lancer dans le bêta-testing.
Comme indiqué ci-dessus, le fait de basculer Jeedom ou un plugin sur une version en cours de développement comporte des risques. Par conséquent, il est fortement recommandé de le faire sur une installation de test prévue à cet effet (une machine virtuelle par exemple) plutôt que sur un Jeedom en production.
Important
L’équipe Jeedom ne peut être tenue responsable de tout dysfonctionnement survenant suite à l’installation d’une version autre que stable. Dans ce cas l’accès au support officiel est impossible, il faut donc faire une remontée.
Jeedom est un logiciel open-source dont le développement peut être suivi en temps réel sur Github. Chaque branche correspondant à différents niveaux d’avancement dans son développement.
INFORMATION
Bien qu’il y ait plus d’une centaine de bêta-testeurs enregistrés sur le forum, nous n’avons que peu de retours concernant les développements en cours (branche
develop). Que ce soit par manque de temps ou de doutes sur ses connaissances techniques, ceux qui souhaitent néanmoins participer aux évolutions de Jeedom peuvent tester la brancherelease(déjà stabilisée en grande partie) avant qu’elle soit mise à disposition en stable à tous les utilisateurs.
Les branches annexes correspondent à des développements indépendants et ponctuels, voués à être intégrés à une branche principale.
develop.develop.master & develop.INFORMATION
xxxxx-yyyyycorrespond au sujet court de la fonctionnalité ou du correctif en question.
A la lecture des Mises en garde exposées précédemment, il est évident que cette manipulation est à réserver aux utilisateurs avancés en toute connaissance de cause.
Pour changer de branche, et donc de version Jeedom, rendez-vous dans le menu Settings → System → Configuration, tab Updates / Market. Laissez la source de mise à jour sur Fault et sélectionnez la version du core (branche) que vous souhaitez installer.
Ensuite, cliquez sur le bouton Sauvegarder puis dirigez-vous vers le menu Settings → System → Update Center. Depuis cette page il ne reste qu’à effectuer une mise à jour du core pour basculer sur la nouvelle version.
Important
En cas de changement de numérotation du core, il est vivement déconseillé de revenir sur une version inférieure (downgrade). Il est plutôt recommandé d’attendre que les modifications arrivent en version stable pour rebasculer dessus.
Concernant les branches annexes, une fois la fonctionnalité ou le correctif testés, il faut revenir sur la version à la base (developdans la majorité des cas).
En master (stable) ou release, chaque nouvelle version entraine un changement de numérotation (x.y.z). Si la case Automatic check for updates est cochée, alors un message de notification sera émis dans Jeedom accompagné d’une pastille rouge dans la barre de menu. Sinon il faut se rendre dans le menu Settings → System → Update Center puis cliquer sur le bouton Check for updates.
À l’inverse, les autres branches n’engendrent pas de notification ni d’alerte dans le centre de mises à jour malgré des modifications régulières. Il revient donc au bêta‑testeur de mettre le core à jour manuellement et régulièrement. Avant chaque phase de tests notamment, et surtout, avant d’effectuer toute remontée afin de s’assurer que le problème n’a pas déjà été corrigé.
The journal des modifications (ou changelog) offre un aperçu des changements apportés par chaque version de Jeedom.
Seules les versions master (stable) et release garantissent la présence d’un changelog détaillé et à jour.
En develop, les intégrations étant continues, le journal des modifications n’est pas encore généré à cette étape. Pour prendre connaissance des changements apportés depuis la dernière version stable, il faut se référer aux notes de version qui listent les Pull Requests validées sur cette branche.
Les branches annexes faisant quant à elles référence à un élément précis, elles ne nécessitent à première vue pas de détails pour être appréhendées.
La présente page s’attarde principalement sur les bêta-tests autour du core Jeedom mais le principe reste sensiblement le même pour les plugins. En effet, les plugins sont mis à disposition en version stable (branche master) par défaut mais ils disposent également de versions beta pour les développements en cours.
Pour accéder aux plugins en version beta, il est nécessaire de cocher la case Activer l’accès aux plugins bêta dans votre profil Market. Il suffit ensuite d’installer ou de réinstaller le plugin dans cette version.
Important
L’installation d’un plugin en version
betafait perdre tout accès au support officiel.
Les bêta‑testeurs sont en première ligne pour identifier un dysfonctionnement, tester une nouvelle fonctionnalité ou valider une correction avant publication en stable.
Après avoir clairement analysé la situation, plusieurs canaux sont disponibles pour effectuer des remontées les plus détaillées possibles avec tout le contexte nécessaire. Quel que soit le canal choisi, la première étape indispensable consiste à effectuer une recherche afin de s’assurer que le sujet n’est pas déjà abordé pour ne pas créer de doublons.
Important
Il est crucial de comprendre un minimum le sujet par soi-même sans se reposer intégralement sur l’analyse d’une intelligence artificielle. Celle-ci peut toutefois rester utile pour la mise en forme de la remontée ou pour ajouter du complément (vérifié).
Les remontées peuvent être formulées directement dans le salon des bêta‑testeurs du forum Jeedom.
Choisissez la section adaptée à la catégorie de la remontée puis ajoutez les étiquettes (tags) en lien avec le sujet (v4_5 par exemple). Il ne reste plus qu’à rédiger votre retour en incluant le maximum d’informations afin que toute personne extérieure soit en mesure de comprendre, de reproduire et d’analyser la situation.
INFORMATION
Le salon des bêta‑testeurs intègre également une section Suggestions pour proposer des améliorations.
Si, après recherche, une issue ou une pull request est déjà ouverte sur le même sujet alors vous pouvez y ajouter votre analyse à condition qu’elle apporte des éléments pertinents dans le cadre du développement concerné.
Sinon, vous pouvez ouvrir une issue sur GitHub détaillant de manière exhaustive le dysfonctionnement rencontré.
INFORMATION
L’anglais est la norme sur GitHub pour que tout un chacun soit en mesure de comprendre le sujet mais nous acceptons les textes rédigés en français.
Que ce soit pour corriger une simple faute d’orthographe ou de syntaxe, ou même pour proposer un changement plus important, tout le monde peut participer au développement et à l’évolution de la solution Jeedom à son niveau.
Les pages de documentation que vous consultez actuellement nécessitent des mises à jour et des adaptations régulières pour rester valables et fiables. L’assistance de la communauté est grandement appréciée à ce niveau.
Quelques spécificités sont à prendre en compte avant de proposer des changements sur la documentation. Il est donc indispensable de prendre connaissance des bonnes pratiques pour contribuer à la documentation en premier lieu.
A l’instar de la documentation, le core Jeedom ainsi que la plupart des plugins sont également ouverts aux contributions externes. Référez-vous à la page “Contribuer au core ou aux plugins” pour en savoir plus.