Changement dans le workflow git

[VForiel]

Je profite de la mise à jour imminente en 1.4 (toutes les PR de la todolist sont désormais closes) pour vous proposer de changer un tout petit peu de workflow git. Pas de gros changement ne vous inquiétez pas, c'est surtout une formalisation d'un truc qu'on fait déjà un peu ... mais mal :

Actuellement on bosse sur beta qui nous sert de branche principale et on push le tout sur main qui sert de branche "stable". Le truc, c'est qu'il n'y a pas tellement besoin d'une branche stable car dans l'usage qu'on en a, un tag qu'on bouge de commit stable en commit stable ferait amplement l'affaire. En revanche, vu qu'on apporte de gros changements d'une mise à jour à l'autre, ceux qui ne suivent pas ces changements se retrouvent un peu emmerdé. C'est pourquoi je propose qu'au lieu d'avoir une branche stable, on ai plusieurs branches correspondant aux LTS (Long Term Support) sur que les utilisateurs pourraient utiliser et sur lesquelles ont peut proposer des correctifs mais on ne fais plus de développement actif dessus (il n'y aura donc normalement qu'une seule grosse PR à l'origine des branches LTS, puis des PR de correctifs

[ascpial]

Ça veut dire que les correctifs devront être fait sur deux branches. La LTS et la beta ?

[VForiel]

Si le correctif s'applique aux deux, alors oui, car une fois la branche LTS créée, la branche main ne sera plus jamais merge dedans, donc il n'y a pas de risque de conflit, les deux branches évolueront indépendamment.

Cela dit, une correctif qui s'applique à 2 branches devrait être rare si le travail de vérification lors de la PR de création des LTS est bien fait. En effet, un correctif peut être dû à une changement récent, auquel cas il ne sera probablement appliqué que sur la branche main, ou bien dû à un très vieux code, auquel cas il y a de fortes chance que les changements sur main aient déjà corrigé le problème (intentionnellement ou non)

[Aeris1One]

Dépends du correctif, et de la version. Il faudrait définir un plan de support.
Par exemple la dernière majeure est supporté en correctifs de bugs/fonctionnalités qui cassent/etc. mais la version encore avant ne l'est plus que pour les problèmes de sécurité...

[ascpial]

Maintenir plusieurs versions à la fois me paraît étrange au vu de la taille du projet.

Ce type de workflow me paraît bien pour une entreprise qui propose des services à d'autres acteurs, et qui a besoin d'un garantie de stabilité, comme par exemple Cannonical avec Ubuntu ou l'entreprise qui gère Nextcloud.

Dans notre cas, nous sommes 3 ou 4 à maintenir ce projet, pour le moment principalement pour notre usage personnel (même si j'ai eu vent de personnes qui avaient tenté d'utiliser le projet pour un usage externe), je ne vois donc pas l'intérêt de gérer plusieurs versions d'un coup.
Je n'ai jamais vu ce genre de workflow dans des petits projets et je penses que c'est entièrement overkill.

Pour le moment, maintenir une version beta de développement et une version stable me paraît bien, si on s'assure que la mise à jour se passe bien sur la branche stable il n'y a pas de nécessité de gérer plusieurs versions.

Dans le futur, si il y a un usage plus répandu (plus d'instances, des plugins externes...) du projet et plus de développeurs actifs, ça pourra être utile, mais comme je l'ai dit pour le moment ça me paraît une perte d'énergie et de temps.

[VForiel]

Rien ne nous force à réellemet maintenir les version "LTS". Je les ai appelé comme ça car mon graphe est un graphe général (que je compte réutiliser pour d'autres projets), mais dans notre cas ça ne peut être que de simples branches liés à une version majeure sur laquelle on ne garanti aucun support

Cela dit, on s'ouvre la possibilité de faire du support, et mieux encore, vu que le projet est open-source, on ouvre la possibilité aux potentiels utilisateurs de faire eux-même des hotfixe sur les versions qu'ils utilisent, afin d'en faire profiter les autres utilisateurs de cette version

[ascpial]

L'idée serait donc d'avoir une branche par version, tout simplement ?

[VForiel]

Oui, qui a terme, si le projet devient plus gros, serviront de branches LTS

[ascpial]

Ça me paraît bien alors.