srosset81
commented
10 months ago La branche next m'a été inspirée par le fonctionnement de React-Admin, mais on a sans doute dévié. Pour React-Admin, dès qu'il y a une PR qui est de l'ordre de la feature ou qui contient des breaking changes, elle doit être mergée sur next. Sinon elle doit être mergée sur master. Il y a ensuite des releases régulières de master avec tous les bug fixes, ce que nous ne faisons pas.
Comme c'est toi qui est le principal maintainer d'Archipelago en ce moment, je te proposerai de faire comme tu préfères. Mais peut-être faire attention à ne pas trop se mettre de contraintes car on est une petite équipe.
Concernant la release de SemApps 0.6, je n'en ai aucune idée en ce moment. Je vais sans doute devoir m'y pencher en décembre car j'aimerais merger la branche next d'ActivityPods (qui a le même problème qu'Archipelago).
Voilà quelques éléments de réflexions, sans doute incomplets mais j'ai trop à faire en ce moment.
Hello,
Actuellement, toutes les évolutions depuis 2 mois se font sur la branche
next, qui correspond à une version 1.2.0 d'Archipelago, il y a également d'autres modifications qui avaient été effectuées directement sur la branchemasterqui ne sont pas actuellement pas pris en compte sur next (il suffirait de rebase).La branche
nextutilise la version 0.6.0-alpha.3 de Semapps.La question qui se pose est quelle est le planning de merge de cette branche
next? Et quand décide-t'on d'arrêter les évolutions sur cette branche pour rebasculer sur master ?Quels problèmes ça pose aujourd'hui ?
Les instances souhaitant utiliser les dernières innovations doivent se baser sur une branche (next), et non sur un tag, ce qui est dangereux car ça ne fige pas le code si un commit est rajouté ensuite. On peut aussi se baser sur le commit, comme je fais actuellement sur une instance, mais c'est un peu galère et pas vraiment prévu pour ça...
Vu que la branche
nextest labellisée 1.2.0, ça empêche de faire des évolutions breaking dessus. On peut toujours la renommer pour ça, mais ça ne fait que déplacer le problèmeQuelles solutions ?
Personnellement je suis habitué aux releases petites et régulières sur les projets, ça permet d'itérer assez vite au fil des changements. Je comprends aussi la nécessité d'avoir créé une branche de release vu que ça intègre une version alpha de Semapps donc pouvant encore contenir des bugs (ce qui fut le cas).
Je propose les solutions suivantes :
1/ Merger la branche next avec la version actuelle de Semapps (en alpha) et release la 1.2.0, puis faire une prochaine release quand Semapps sera sorti en version 0.6.0.
Avantage : Non-bloquant pour les futures releases à venir.
Inconvénient : Intègre une version alpha de Semapps
2/ Considérer que Semapps 0.6.0 est prêt à être release, le release et mettre à jour la version de Semapps avant de faire la release. Avantage : La version de Semapps est stable dans la release Inconvénient : Bloque la progression des versions d'Archipelago si Semapps mets du temps à release
Pour la suite
Que préférons-nous décider pour les futures releases d'Archipelago ?
1/ Une branche
nextpour chaque release, qui peut exister pendant des mois avant de décider de la merger.Avantage : Releases potentiellement plus stables car largement éprouvées Inconvénient : Vélocité des mises-à-jour freinées par la durée entre les releases. Releases potentiellement conséquentes en changements (peut complexifier l'upgrade d'une version à une autre ?)
2/ Faire des releases à chaque PR ou groupe de PR mergées directement sur master. Avantage : Evolutions released au fil de l'eau, les instances peuvent rapidement les intégrer Inconvénient : Beaucoup de releases créés si beaucoup d'activité sur le repo
3/ Une solution hybride où on décide de fixer une deadline à release si ça traine trop longtemps. Si une branche next est créée depuis plus de X jours (par exemple 1 mois), on décide de la merger avec les évolutions actuelles dessus. Avantage : Cadencement des releases pour éviter d'en avoir trop Inconvénient : 🤔
Que pensez-vous de mes réflexions ?