Re: Re: Hold off 5.4

On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: > On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner <mike@php.net> wrote: >> On 11/23/2010 02:30 AM, Felipe Pena wrote: > >>> 5.4 should be hold off until we solved the listed issues and the >>> release management RFC gets discussed and hopefully approved. The reality is that trunk is not going to be 5.4; it cannot be in its current state. The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing. The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This is an unreliable, laborious, crappy method for creating stable branches, and managing the repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and re-integrating is also a pretty crappy solution. So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work. Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now. We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits. This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories to more easily pull those changes into the appropriate branches. - Davey