2010/11/25 Davey Shafik <da...@php.net>: > > 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
I think Davey has a clear view and a good explanation about the current situation. Trunk has been used for both short and long term development hence the difficulties to agree that trunk is about 5.4 or +. In a first place, we should decide on what to have for 5.4 and what to leave for the future. A technical way to do it would be to use git-svn locally, starting from the PHP_5_3 branch and merging it with trunk. git rebase -i can then be used easily to remove all the commits we don't want to appear in 5.4. -- Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
