Re: Branching PHP6

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. > 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. 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. johannes