Hello,
> I think we also need a "Release Manager" ;)
>
> - create the branch
> - tag the version
> - create / publish the tarball
> - check which commits can go in the branch after a RC.
I'm pretty OK with that.
> And perhaps we also need a "9.1.1" branch
>
> So only "critical" remaining bugs
it's now
compatible with the current code.
It will avoid errors like incomplete tarballs.
Regards.
- Mail original -
> De: "Remi Collet" <fed...@famillecollet.com>
> À: glpi-dev@gna.org
> Envoyé: Dimanche 16 Octobre 2016 12:07:44
> Objet: Re: [Glpi-dev] Bra
I think we also need a "Release Manager" ;)
- create the branch
- tag the version
- create / publish the tarball
- check which commits can go in the branch after a RC.
And perhaps we also need a "9.1.1" branch
So only "critical" remaining bugs can go there, and allow dev to
continue fixing bug
Le 10/10/2016 à 10:04, Johan Cwiklinski a écrit :
>> All old developers know that you must always fix in current version.
>> If it's a new developer it's a mistake of his tutor should have seen the
>> problem.
>
> New developer or not, having some documentation we can rely on and check when
>
Le 06/10/2016 à 20:43, Johan Cwiklinski a écrit :
Hello,
Hi,
I don't understand this "new" workflow because it's not one (it's the
same since very long time)
This is nothing new, and this sounds logical to me.
For bug in stable version => correction in stable bugfix and master
version
ev-boun...@gna.org] On Behalf Of Johan
> Cwiklinski
> Sent: Wednesday, October 05, 2016 9:44 PM
> To: Liste de diffusion des developpeurs GLPI
> Subject: [Glpi-dev] Branching rules
>
>
>
> Hello all,
>
>
>
> There is one "important" point I've
