Proposition : workflow de releases

La pratique c'est que ça arrivera. Dans ce cas je propose de faire une PR du merge et de le traiter comme une PR normale.

Ok.

Qu'entends-tu par "faire du site web" ? Est-ce que pour toi ça sous-entends faire plus d'une mise en production par semaine une fois la bêta finie ?

Faire du site Web, c'est developper un truc super changeant. Je ne vois pas pourquoi un bug qui fait chier tout le monde devrait attendre plus de 2 semaines par exemple en préprod avant de passer en prod. Pour moi on devrait faire des livraisons dès que les tests en préprod est concluant (au moins 1 semaine par contre).

Le tag a vocation à deux choses :

1- Indiquer aux visiteurs sur quelle version ils en sont (pour les rapports de bug)

2- Pouvoir récupérer instantanément la version problématique en prod, que ce soit l'actuelle ou une vieille.

Bah si ce sont là les vocations du tag, le hash aussi rempli très bien ce boulot, c'est bien la nécessité du tag que je ne comprends pas. A part si on veut tenir un historique des versions mis en prod, je n'en vois pas trop l'intérêt. L'utilisateur aujourd'hui quand il remarque un bug, il suffit qu'il donne le hash (marqué dans le footer) pour que le dev retrouve quelle version du projet il l'avait sous les yeux. Un tag pour moi c'est quelque chose de vraiment gros, du genre, on passe de la v1.0 à la v1.1.

Je parlais de tester le workflow que je présente. A savoir manipuler les branches de facon un peu plus avancée.