Re: Towards 5.3.2

As Lukas pointed out, both approaches have flaws, but I think the new merging approach is much cleaner and prevents people from committing during a freeze. Although the wiki might not be the perfect place to do things, I think the general approach is good. Core developers should know what's going on in the wiki, or at least don't complain. Cheers On 2009-12-07, Ilia Alshanetsky <ilia@prohost.org> wrote: > Pierre, > > Actually patches were indeed missed, in fact we almost missed a security fix. As far as the > wiki goes, most people don't even know it exists, let alone where to find it. Also, looking at > the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little > indication as to why they didn't. > > > On 2009-12-07, at 8:46 AM, Pierre Joye wrote: > >> 2009/12/7 Ilia Alshanetsky <ilia@prohost.org>: >>> Johannes, >>> >>> While the separate branch release for 5.3.1 was a worthwhile experiment, I think it >>> creates too much opportunity for missed patches and quite frankly makes the whole release process >>> confusing and complicated. My personal preference would be that 5.3.2, not be released from a >>> separate branch. >> >> It was actually the exact opposite. We did not miss patches once we >> were synced. The way we tracked the patches also let us actually >> define what must go in and what not, avoiding the classical last >> minute bad patches. The key to success is to do not let go months >> between a commit and its merge to the release branch, which was a real >> pain when we began 5.3.1. >> >> Cheers, >> -- >> Pierre >> >> http://blog.thepimp.net | >> http://www.libgd.org >