Who says it has to be 5.4? People seem to be a bit fixated on the version there. Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number.
Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen.. ---Jani On Nov 25, 2010, at 9:16 AM, Davey Shafik wrote: > > On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: > >> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner <m...@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 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
