Core Alpha 4.4
On demande souvent ici même la page santé afin d’avoir une vue d’ensemble sur la solution pour aider les gens.
Je pense qu’il serait pertinent au niveau de la version d’avoir en plus du numéro
stable / beta ou alpha.
Bonjour
C’est pas si simple car jeedom ne le sais pas. Il sait la branche a utilisé pour la maj a jour mais ne sais pas d’où viennent les fichiers qu’il utilise actuellement. En gros si l’utilisateur passe de beta a stable sans faire de maj ça afficherait stable alors que c’est toujours la beta vu qu’il n’y a pas eu de maj.
Ne peut on pas imaginer avoir un fichier quelque part qui contient l’info stable / beta ou alpha, fichier qui est poussé lors d’une mise à jour et y récupérer l’info ?
Ca veut dire qu’a chaque passage alpha → beta → stable il faut que j’edite le fichier et les merge d’après passeront plus après en plus… Et posé le fichier a l’update par le jeedom ca pourrait etre faut aussi si l’utilisateur patch a la main.
Bon on laisse tomber lol
Désolé l’idée est bonne si je trouve comment faire je ferais mais la comme ca je vois pas de moyen infaillible.
1 « J'aime »
Bonjour,
En éditant le fichier : /var/www/html/core/config/version
- Par exemple, j’ai ajouté : un f à 4.3.17
Et cela devrait suffire à identifier l’origine du Jeedom :
x.xx.a : Alpha
x.xx.b : Bêta
x.xx : Stable
Bonjour
Oui mais ça change pas mon soucis, ça serait un fichier de version pas branché que je dois donc penser à éditer a chaque sortie de nouvelle version et qui sera en conflit a chaque merge. En gros a chaque fois qu’il y a une nouvelle version c’est 10min de boulot en plus, sachant que en beta j’en fait plusieurs par jour je ne sais plus avec ça quand je pourrais travailler sur jeedom
Je ne suis pas sûr d’avoir compris la question… Mais en fait, la bonne solution serait d’avoir une gestion des branches un peu plus conventionelle 
Je me suis fait la réflexion sur ce sujet en lisant la doc contribution:
- alpha : Branche de la version V4 alpha. Principalement destinée aux développeurs pour la version suivante de Jeedom.
- beta : Branche de la version V4 beta. Principalement destinée aux beta-testeurs, pour tester avant passage en Stable.
- V4-stable : Branche stable de V4.
- release : Branche Release Candidate de la V3. Uniquement pour des bugfixs.
- master : Branche de la version stable V3.
respecter la norme
- master = 4.3 (la version stable en cours)
- develop = 4.4 (la version beta)
- des branches spécifiques pour les versions précédentes, pourquoi pas: V3-stable, V4.2-stable …
- pas de alpha => on crée des branches ‹ feature › ou ‹ bugfix › ou peu importe, que l’on supprime dès que c’est dans develop.
Après, pour la gestion du fichier de version, il existe des solutions automatisées: le ‹ plugin › semantic-release gère cela, à la fois les versions et même le changelog, mais pour que ça marche bien il faut être psychorigide sur les messages de commit.
Bonjour,
Honnetement j’aimerais mais je n’ai pas les compétences pour mettre tout ca en place et ca me prendrais trop de temps. Déja quand je vois que quand j’annonce que le plugin zigbee n’aura pas de support quelques semaines pour que je puisse me concentrer sur le nouveau ca rale, alors imagine si je dis je prends quelques semaines ou je fais plus de support/forum/mise à jour/maintenance sur rien du tout pour mettre ca en place…
no problemo, je propose juste mais c’est pas à toi de tout faire 
Je vais tester sur mon plugin, si ça se passe bien je ferais pareil ou équivalent pour Jeedom.
« LA » norme? Celle là: xkcd: Standards ?
Soyons sérieux deux minutes, il n’existe pas une norme unique et meilleure que toutes les autres
Il y a toujours un contexte à prendre en compte.
Mais soit, la question n’était pas là mais sur le numéro de version
Perso quand je lis ça:
On sait déjà que ça ne va pas être gagné…
Mon avis sur la question d’origine est que ok ça serait un petit plus mais en fait avec la numéro de version, on sait déjà si c’est une stable ou une bêta et au final même cette info n’est pas tellement importante je pense, seul le numéro de version l’est;
Que ça soit une 4.4 stable ou une 4.4 bêta ne change rien, c’est une 4.4.
Donc si ça prenait 15 min à faire une fois pour toute ok mais pas la peine d’y consacrer plus de temps.
non je voulais parler de cette norme (et il n’y en a pas 36 concernant le versionning) :
Ce serait une bonne idée de le mettre en place, parce que, même si ça prendra probablement un peu plus de 15 min à implémenter, si ça peut faire gagner 10 min à chaque fois que Loic ou d’autres font des merge entre alpha / beta / stable, le gain est énorme, sur la durée.
Mais, comme la magie n’existe pas, ça se fait au prix d’une syntaxe stricte dans les messages de commit, et la en effet c’est pas gagné 
Bonjour,
Juste pour information, sur git il y a une méthode pour organiser les branches : gitflow
Après, est ce utile pour répondre à la question initiale (savoir si beta, alpha ou stable), et le temps de mise en place en rapport à la disponibilité et à La taille de la structure de Jeedom SAS, c’est un vrai débat.
Question que je me suis déjà posé : pourquoi Jeedom ne prendrais pas des stagiaires ou des alternants un moment pour faire des tâches utiles mais chronophage ?
Le suivi est parfois complexe et prend du temps.
Je pensais à la modification de documentation, mise en place de git, test sous docker,…
Notre entreprise procède comme cela, c’est très capitaliste et exploitation, mais si Jeedom ne peut pas embaucher plus de monde…
Pifou intervient souvent pour aider sous github et docker et c’est plutôt cool.
1 « J'aime »
Bonjour
Car prendre des stagiaires et intervenants c’est aussi chronophage et qu’il faut les encadrer sinon ça ne sert a rien. La toute les employés de jeedom sas sont a 100% et ne peuvent donc pas encadrer une personne. Et je rappelle aussi que je ne travail pas pour jeedom sas et donc que j’ai un boulot à côté donc je ne peux pas le faire.
Oui, c’est sûr que c’est chronophage. C’est rentable si la personne reste longtemps (style alternant)
Bon courage à vous tous, car j’imagine bien que vous êtes à 100% très souvent.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.