Yes, IF you're using a proper branching model. If you're just using it the same way you'd use Subversion, which currently is the direction we seem to be moving in, those advantages are mostly negated.
I agree that PHP 5.5 (and maybe even 5.6, etc) should come before PHP 6. That being said, at some point a parallel development workflow might be prudent IMHO, but even that would be a ways off I think. --Kris On Tue, Mar 13, 2012 at 11:55 AM, Richard Lynch <c...@l-i-e.com> wrote: > On Fri, March 2, 2012 4:26 am, Ferenc Kovacs wrote: > > If we can agree upon the next version number beforehand, and we decide > > that > > we will go with the major release (be that php 6 or 7, whatever), we > > don't > > to do anything right now, we can branch the version from trunk/master, > > when > > the time comes. > > If we can't agree upon the next version number, or we agree upon that > > there > > will be an 5.5 version, I think it would make sense to create a branch > > for > > it ASAP, so there is place (trunk/master) for the approved but > > backward > > incompatible changes, and people don't have to hold patches. > > What do you think? > > If I was in charge, and thankfully I'm not, I'd just create 5.5 and 6.0 > > If you have patches that don't break BC, put them in both. If you're > too busy to do both, put it in 6.0 Somebody will back-port or not, > based on their relative need/availability or not. > > If it breaks BC, put it in 6.0 > > Or perhaps I misunderstand the tiny bit I thought I "got it" of the > point of using Git in the first place... > > Branches and merges are supposed to be seamless, right??? > > -- > brain cancer update: > http://richardlynch.blogspot.com/search/label/brain%20tumor > Donate: > > https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
