Re: Re: Hold off 5.4

2010/11/25 Davey Shafik <davey@php.net>: > > 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 > -- > 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