Re: Branching PHP6

On Thu, Apr 3, 2014 at 5:20 AM, Johannes Schlüter <johannes@schlueters.de>wrote: > On Thu, 2014-04-03 at 04:32 -0700, Kris Craig wrote: > > By release branch, are you referring to minor releases or maintenance > > releases? If the latter, it'd be a moot point under this model because > > we'd be getting rid of separate branches for maintenance releases > > altogether. Instead, the RM would simply apply the tag to the commit > where > > they want the maintenance release to occur. That would be a much cleaner > > approach than what we're doing now. > > The past shows that in practice this won't work. We had enough incidents > in the past where "small" changes after an RC roe the release. That's > why we created the strict rule of using those release branches. > That wouldn't happen if the RM controlled commits to the minor release branch. > > > If you want to continue having a gatekeeper approach with only one person > > having access to a minor increment branch, a simple alternative would be > to > > have people push their feature branches if they believe the commits > should > > go on one or more minor increments. Then, the release manager for each > > minor increment (i.e. there'd be an RM for 6.0 and 6.1 instead of for > each > > individual maintenance increment) would decide whether or not to merge > that > > feature branch in. The feature branch itself would be based on a minor > > release branch and subsequently deleted after it's either merged or > > rejected. > > Neither do we have the resources for constant gatekeeping nor is that > the spirit. In general we trust developers to do the right things and > prefer fixing mistakes afterwards over preventing improvements by > process. > Actually, that's extremely easy to accomplish with Git. Gitolite, for example, enables the use of branch-specific permissions for different users.. Besides, my point was that this branching model can easily accommodate both scenarios with and without a gatekeeper. > > The reason why we have the "ugly" history comes more from the fact that > we have long living feature branches branched of quite some time ago > (i.e. pull requests) which then are merged in, instead of e.e. rebaseing > the first. > > That's part of it, but I've also noticed a ton of criss-crossed merging happening between version branches. That, more than anything I think, makes it a nightmare to read. Furthermore, there's simply no need to have an ever-increasing number of dead branches that lead nowhere and never merge back. If somebody wants to find a specific version, that's what tags are for. --Kris