Re: Branching PHP6

On Thu, Apr 3, 2014 at 4:19 AM, Johannes Schlüter <johannes@schlueters.de>wrote: > On Thu, 2014-04-03 at 04:06 -0700, Kris Craig wrote: > > I think we should use this opportunity to start following a more > Git-style > > branching model. Currently, every maintenance release increment exists > as > > its own separate branch; i.e. "PHP-5.5.10" is a branch and > > "PHP-5.5.11" > is > > a branch, and so on. This is redundant because we already have a tag for > > each release. Additionally, it also forces us to target features for one > > or more specific maintenance version increments. A more flexible > approach > > would be to have each increment reflect the totality of what's been > merged > > in as stable as of whenever the increment went to release. > > These release branches are owned by the RM. No other developers should > touch them. The only commits there should be related to release process > or critical cherry picked fixes. > The decision the developer has to make is whether a change should make > 5.4, 5.5, 5.6 or newer, not the actual release. New features should only > be merged in the top most branch. > 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. 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. --Kris