Re: Branching PHP6

On Sat, Apr 5, 2014 at 11:43 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > Hi! > > > A github fork of a semi-active PHP core developer likely has at least > > ten additional "active" (as in, not yet merged) branches. > > These branches are in dev's private fork, so I'm pretty confident the > devs can manage their own backyard. They also don't have to import every > branch from main repo to their private repo, AFAIK. > > > I think keeping around dead branches does have a cost. It blows up > > branch listings significantly. If you open the branch list on github and > > try to find something you'll end up scrolling through more than fifty > > release branches and other dead ends. > > It has a completion widget there, and I still not sure what is > "something" you're looking for there. Is it "PHP-5.6"? It's not > hard to > find then, you know its name. The issue seems to me getting much more > attention than it deserves. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > You are correct in that it's not a catastrophic issue or anything. But even if it's not that big a deal, it's still a mess. And I guess the point I'm making is that, if there's a cleaner way of doing this that doesn't introduce any costs or other drawbacks (which there is and it doesn't), then why not do it the cleaner way going forward starting with PHP 6? Here's a quick breakdown of what we'd be looking at: - Release managers would continue to have exclusive commit access to release branches. - Current and past versions would still be quickly and easily accessible via tags, just as they are now. - Branching would better reflect segregation of maintenance releases from trunk commits. - Feature branching would be consistent and would not add to clutter. - The corpses of old EOL branches would no longer pile-up and linger for eternity. - The reduced clutter will make it easier to locate active branches and much easier to read and make sense of the commit history. On the flip side, there really aren't any drawbacks. The only case against doing this that I'm seeing is "it's no big deal". Maybe it's not that big a deal, but it's still an improvement that doesn't introduce any adverse consequences. I realize that some people who are still Git-weary might be a little reluctant to tweak the branching procedure at all, but it's really not as complicated as it sounds. --Kris