Gestion du dépôt avec un GitFlow

[ldez]

Passage à un GitFlow afin de mieux gérer les versions.

Pour résumé :

• master : version en cours (prod)
• develop : version en cours de dev
• release : branche dédié aux release

Ressources :

• https://fr.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
• http://danielkummer.github.io/git-flow-cheatsheet/
• https://datasift.github.io/gitflow/GitFlowForGitHub.html
• https://datasift.github.io/gitflow/IntroducingGitFlow.html

[ggerbaud]

Alors oui ça pourrait être mieux géré mais là c'est overkill. Il n'est pas prévu pour le moment de maintenir plusieurs versions en //

[ldez]

la version 0.5.0 va être une rupture qui va impacter les formations, dans un premier temps avoir 2 version en parallèle me parait justifié pour ne avoir à corriger toutes les formations d'un coup.

[hgwood]

Un master avec des tags n'est pas suffisant ?

[ldez]

Actuellement, le problème c'est que la version en cours de dev (master) est considéré comme 'latest' et cela rend l'utilisation des images dockers impossible avec le bon rendu.

[hgwood]

OK donc avec une git flow, 'latest' désignerait une version stable. Mais on aurait toujours le problème de #81, non ? Où ça n'a rien à voir ?

[ldez]

en fait quelque soit la solution l'objectif c'est de pouvoir avoir une 0.4.2 (Reveal 2 et Node 3) et une 0.5.0 (Reveal 3 et Node 3)

[jlandure]

Hypothèse : nous parlons du fmk--formation ^^ Le gitflow me parait effectivement overkill... Je ferai simple :

• latest = 0.5.0 = reveal3/node3 = la version qui a le plus d'avenir
• 0.4.2 = reveal2/node3

[ldez]

• 0.4.2 = reveal2/node2 (avec option node3 partiel)

Je ne suis pas sur pour le latest car la 0.5.0 n'est pas prête, je dirais simplement qu'il faut 2 branches :

• master
• develop

[jlandure]

master et release comme sur les projets de formation, ça serait pas mal non ? du coup, release = latest côté image docker.

[ldez]

:+1: