creation auto de sujets pour les tuto en beta

[firm1]

Q	R
Correction de bugs ?	non
Nouvelle Fonctionnalité ?	oui
Tickets concernés	#991

Cette PR permet de faire ceci:

• Lorsqu'on mets en beta une version de notre tuto, un sujet est crée dans le forum beta (paramètrable dans le settings), et l'auteur de la mise en beta follow automatiquement le topic
• On peut donc commenter la version beta sur le topic
• Lorsqu'on arrête la beta sur une version de notre tutoriel, le sujet en question est locké
• Si on réactive la beta sur la même version, le sujet est dévérouillé
• Si on mets à jour la beta sur une autre version, un message est posté sur le topic pour prévénir de la nouvelle version.

Note pour la QA

Vérifiez que ça se passe bien comme prévu.

[coveralls]

Coverage increased (+0.18%) when pulling 2e3fddb on beta-tuto-behavior into efc3324 on master.

[Alex-D]

C'est clairement une nouvelle feature, est-ce que ça n'irait pas plutôt dans la branche dev ?

[Alex-D]

Le test me semble un peu léger non ?

[firm1]

C'est clairement une nouvelle feature, est-ce que ça n'irait pas plutôt dans la branche dev ?

Vu les conflits entre la dev et la master, je préfère appliquer ça sur la master bien plus sure et éprouvée.

[Eskimon]

Dans ces cas la a quoi ca sert qu'il y est une branche dev ?

[firm1]

Dans ces cas la a quoi ca sert qu'il y est une branche dev ?

Bonne question.

[Taluu]

Vous connaissez mon avis sur le sujet... Je pense que cette branche ets superflue quand on fait pas de release. Ou quand on se base sur une rolling release. Besoin de release quelque chose ? Plutôt que de freezer la branche principale, autant faire une nouvelle branche qu'on fixe, on répercute les commits sur les deux branches.

[Alex-D]

Donc on merge dev dans master et on continue dans master en supprimant dev et en repassant master en branche principale. GO GO GO :)

[Eskimon]

Ou alors on bosse dans Master en attendant un consensus sur ce sujet : http://zestedesavoir.com/forums/sujet/445/modele-de-branches/

[firm1]

Ou alors on lit simplement la doc ? :P

[Alex-D]

C'est ce que je dis : la master de "la doc" c'est notre branche prod, et on dev sur master. Donc y a pas à chercher 15 ans.

[firm1]

C'est ce que je dis : la master de "la doc" c'est notre branche prod, et on dev sur master.

Et la realease branch dans tout ça tu en fais quoi ? Je rappelle qu'on est toujours en release pour atteindre la v1

[Taluu]

nan mais la branche de release (notre master) ne sert à rien. enfin, pardon, la branche de dev ne sert à rien, justement comme tu le dis toi-même :

C'est clairement une nouvelle feature, est-ce que ça n'irait pas plutôt dans la branche dev ?

Vu les conflits entre la dev et la master, je préfère appliquer ça sur la master bien plus sure et éprouvée.

donc autant adopter un principe de rolling release. Quand on a besoin de préparer une release (on est sur de pas dévelopepr de nouvelles features, sinon elles se font sur la branche principale et nous foutent la paix), alors là on peut éventuellement créer une branche de release, qu'on peut scraper / renommer en prod en crashant l'ancienne branche de prod.

On a comme ca une branche de prod clean, sans avoir des merges oedipien dans tous les sens. Mais ici ce n'est certainement pas le sujet.

[firm1]

donc autant adopter un principe de rolling release [...]

En gros, on adopte plus le gitflow ? Dans ce cas, il faudrait aller en parler en dev zone.

[SpaceFox]

Je passe pour dire que j'en ai sérieusement ma claque que ce sujet revienne encore, encore et encore sur la table.

Encore une fois je ne comprends pas ce qu'il y a de compliqué dans le flow qu'on a définis ENSEMBLE. Mais visiblement il heurte vos convictions religieuses, ou vous refusez de prendre les 2 minutes nécessaires pour essayer de le comprendre.

Alors pour résumer :

1. SI, on fait des releases. C'est DOCUMENTÉ depuis plus d'une semaine sur le site. Celui qu'on développe.
2. Toutes les discussions au sujet du processus de développement doivent avoir lieu SUR LE SITE et pas ici.
3. Ce genre de conneries n'a rien à faire ici, même pour rire, même.pour troller :

   Donc on merge dev dans master et on continue dans master en supprimant dev et en repassant master en branche principale. GO GO GO :)

4. Dev = features, Master = release en cours (OUI on fait des releases, on est sur la 1.0 comme le dit le nom du dernier tag : « v1.0-RC6 ») = que des corrections. Et bien sûr prod = prod.
   Est-ce que quelqu'un est vraiment incapable de comprendre une règle aussi simple !?

Pour le reste je suis en vacances et en connnexion GPRSA quand j'ai de la data… n'espérez même pas une réaction rapide avant lundi.

[Taluu]

La discussion continue ici donc : http://zestedesavoir.com/forums/sujet/445/modele-de-branches/?page=1#p11221

[Alex-D]

Dev = features

Voilà, tu peux fermer la PR et la refaire dans dev. C'est tout ce que je dis. Si tu veux qu'on suive la même logique pour tout le monde @firm1, il faut que toi le premier tu la mette en application.

De plus, la feature est tagguée v2

[SpaceFox]

Voilà, tu peux fermer la PR et la refaire dans dev.

De plus, la feature est tagguée v2

Tout est dit.

[firm1]

Pour que je fasse la PR vers la dev, il faut que la branche dev rattrape son retard, ce qui n'est pas encore le cas actuellement. Du coup je laisse cette branche là comme ça vivante que je synchroniserait au fur et a mesure. Je n'ai vraiment pas envie de coder un truc pour le reprendre complètement plus tard pour cause de conflits.