Date: Tue, 15 Oct 2013 07:48:24 -0400> From: marc@infomarc.info To: phpmyadmin-devel@lists.sf.net Subject: Re: [Phpmyadmin-devel] Git branch workflow summary
(Hmmm, I replied yesterday, here is another reply.)
J.M, do you have a specific question about this? I think there was a discussion about branches on this list a while ago.
There is no formal release cycle. About lifetime, we give a hint on the Downloads page of phpmyadmin.net.
I mean, something like when QA_* branches are created, which fixes are done where, etc. Take a look here for an example: http://nvie.com/posts/a-successful-git-branching-model/ - JM
-- Marc Delisle http://infomarc.info
October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clk... _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
J. M. a écrit :
Date: Tue, 15 Oct 2013 07:48:24 -0400> From: marc@infomarc.info To: phpmyadmin-devel@lists.sf.net Subject: Re: [Phpmyadmin-devel] Git branch workflow summary
(Hmmm, I replied yesterday, here is another reply.)
J.M, do you have a specific question about this? I think there was a discussion about branches on this list a while ago.
There is no formal release cycle. About lifetime, we give a hint on the Downloads page of phpmyadmin.net.
I mean, something like when QA_* branches are created, which fixes are done where, etc. Take a look here for an example: http://nvie.com/posts/a-successful-git-branching-model/
- JM
The QA_4_1 branch will start when the first release candidate for 4.1.0 is published. It will then receive fixes for 4.1.x.
This means that when 4.1.0-rc1 is published, we can resume adding features in the master branch.
We try to fix bugs in the most recent QA branch, so that users of the stable family can benefit from the fix. Sometimes, the fix is evaluated as being either not urgent or risky for the current QA, so it's done only in master.