supprimer la branche next ou pas

[simonLouvet]

@mguihal
Lors de création de la release 1.2, la branche next a été supprimée.
Les instances de Nantes du copil de transiscope et bientôt du mans etait basé sur la branch next ce qui provoque une anomalie lors du build (relativement facile à coutourner en changeant la branche récupérée).
Ma question : Lors du merge de la branche next sur master pour créer des release, doit on supprimer la branche Next ou est il plus cohérent de la garder active pour continuer les prochains développements?
@srosset81 @fluidlog

[mguihal]

C'était un compromis de baser les instances sur la branche next, vu la durée de la branche avant qu'elle ne soit mergée, mais celles-ci ne devraient se baser que sur des versions fixes (les tags), pour éviter que leur build change à chaque nouveau commit/merge, et que leur code soit figé (hors intervention volontaire de montée de version)

Je préconise donc de changer les Dockerfile des instances qui étaient basées sur next, pour les remettre comme avant basées sur un tag (le tag v1.2.0 correspond aux derniers commits de l'ancienne branche next)

[simonLouvet]

je suis d'accord.
Je pense par contre que la branche next doit rester

[srosset81]

@simonLouvet La branche next n'a de sens que lorsque nous travaillons sur des changements importants, qui peuvent entraîner des régressions ou des breaking changes. Pour les évolutions régulières, les changements peuvent être fait sur la branche master, et une branche next est inutile (et c'est du travail à maintenir la synchronisation avec la branche master)

[simonLouvet]

C'est ok pour moi de ne pas garder la branche next, j'avais cependant l'impression que la branche next de semapps (6 mois) servait à implémenter les évolutions majeures que nous allions mergé dans master pour faire des release et qu'elle n'était pas supprimée lors de la création de cette release. Je pensais qu'on appliquerait que la même chose pour archipelago.

[mguihal]

Ce que je ne veux pas justement c'est avoir des branches parallèles qui durent sur le long terme, la branche next de Semapps pour moi pourrait être mergée depuis longtemps sur master, je ne vois pas ce qu'elle apporte de plus, à part de la confusion vis-à-vis des utilisateurs.

Je ne sais pas si vous avez vu, mais contrairement à mon premier message, j'ai créé une branche "next-v2.0.0" ce WE (que je n'ai pas nommé next pour le cas où des instances utilisent tjrs la branche next justement, pour ne rien casser...). Ca a du sens pour moi dans ce cas car c'est une version majeure, avec des breaking changes. Ca permet aussi de mutualiser les breakings changes dans une seule version, vu qu'il risque y en avoir d'autres dans les semaines à venir, sans avoir à monter en v3, v4 ou v5 en quelques semaines seulement. Toutefois, comme précisé dans les solutions que j'évoquais dans l'issue #152 , j'ai mis une deadline d'un mois dessus, pour éviter qu'elle traine trop. Cela n'empêche pas de merger en parallèle sur master des PR de type Minor ou Patch, elles seront synchronisées régulièrement sur cette branche.

J'ai essayé de faire un schéma, mais je ne sais pas si c'est plus clair ou plus confus 😅

%%{init: { 'gitGraph': {'mainBranchName': 'master'}} }%%
      gitGraph
        commit
        commit tag: "v1.2.0"
        branch next-v2.0.0
        branch feat-major1
        commit
        checkout master
        branch feat-minor
        commit
        commit
        checkout master
        merge feat-minor tag: "v1.3.0"
        checkout next-v2.0.0
        merge master
        checkout feat-major1
        commit
        checkout next-v2.0.0
        merge feat-major1
        branch feat-major2
        commit
        commit
        checkout next-v2.0.0
        merge feat-major2
        checkout master
        merge next-v2.0.0 tag: "v2.0.0"

Loading

[srosset81]

C'est ok pour moi de ne pas garder la branche next, j'avais cependant l'impression que la branche next de semapps (6 mois) servait à implémenter les évolutions majeures que nous allions mergé dans master pour faire des release et qu'elle n'était pas supprimée lors de la création de cette release. Je pensais qu'on appliquerait que la même chose pour archipelago.

Non, on applique la même règle pour SemApps... mais comme signalé par @mguihal ça n'a effectivement pas de sens de la laisser aussi longtemps. C'est juste dû à un manque de temps... qui est lui-même dû à une absence de budget pour maintenir le coeur.

Super le schéma ci-dessous ! Il y a une chose que j'ajouterai: lors de release majeure, c'est bien de garder une branche avec la version précédente (p.ex. 1.x). C'est ce qu'on essaie d'appliquer avec SemApps et ActivityPods. Ca permet d'appliquer facilement des hot fixes, lorsque des sites sont "coincés" sur une ancienne version.