Salut,
L’une des remarques sur un post m’a fait me poser une question.
Quand on fait une PR, il faut toujours la faire sur la branche alpha pour que ce soit intégré à Jeedom 4.5 (ou 4.6, 4.7 …) ou bien cette branche est KO et il faut PR sur la bêta ?
Merci,
Bison
Bien intéressé par la réponse… j’ai fais deux PR sur des branches beta et j’espère ne pas m’être trompé:
Hello,
Sur des plugins je pense que tu es bon, pas trop le choix 
Par contre sur le core … je ne sais plus trop
Bonjour
On est en train de revoir le système de branche sur le côté l’idée c’est une branche qui sera la prochaine version majeur avec les nouveautés une pour les corrections de bug qui sera la prochaine version mineur et la master qui est la stable.
Tout n’est pas encore au point car pour les bugs ce système nous oblige à faire des pr sur 2 branches… notre but et de finaliser tout ça pour janvier histoire de pouvoir se lancer à fond dans la 4.6
Salut Loïc,
Merci pour le retour
Nous devrons donc refaire les PR sur le core quand les nouvelles branches seront prêtes ?
Bonjour,
on est d’accord qu’un numéro de version est de la forme MAJEUR.MINEUR.CORRECTIF ? : Gestion sémantique de version 2.0.0 | Semantic Versioning
akenad
Salut,
Pas trop d’inquiétude à avoir à ce niveau, il est tout à fait possible d’adapter la branche qui va recevoir les modifications sans avoir à refaire de PR :
Ah, OK merci 
Du coup j’imagine que vous communiquerez quand ce sera prêt et que l’on devra modifier les PR pour réorienter sur les bonnes branches ?
Non je m’occuperai moi de tout deplacer
C’était déjà un peu le cas il me semble:
Bonjour, ce n’est pas une bonne idée de modifier la branche cible 
Si je fais une PR sur alpha, je fork alpha, je commit mes modifs et je PR sur alpha
Mais, si je fais une PR sur beta, je pars de la branche beta, puis je modifie, commit, et PR sur beta. Même source = même cible.
Si tu prends ma PR faite sur alpha et que tu la modifie sur beta par exemple, ça revient à merger aussi tous les précédents commits de alpha sur beta, et ce n’est peut-être pas ce que tu voulais faire! Dans ce cas il vaut mieux faire un cherry-pick pour reporter le seul commit concerné.
Par exemple quelqu’un a fait une PR sur la branche dédiée trixie, mais on voit bien qu’il n’est pas parti de celle-ci et la PR embarque un tas d’autres précédents commits probablement de alpha. Il vaut mieux être vigilant sur les merges.
y’a plus de beta/alpha. Disons que pour 2026 on arrête de trouver des problèmes partout et on fait simple : tu veux proposer une PR tu pars de la master vers la 4.X.X qui sera la prochaine master. en cas d’issue une branche dédiée peut être ouverte sur le core également, bref rien de plus simple finalement.
Il n’y a pas trop de problème à rebaser normalement.
Ca c’est différent, la PR ne pourra donc pas être mergée sur la branche trixie oui mais c’est normal s’il est parti d’une autre branche que celle de la fonctionnalité concernée !
Super nouvelle ça, on va pouvoir livrer plus souvent, on va devenir agile 
Par contre, comment comptez-vous gérer la quarantaine de PR en souffrance, certaines vieilles d’un an ? Il faudrait peut être les rebase +changer de cible sur master aussi ?