On Thu, Apr 3, 2014 at 4:32 AM, Kris Craig <kris.craig@gmail.com> wrote:
>
>
>
> 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
>
>
So, for example, if I'm committing a new feature or whatever, I'd just
merge it into PHP-6 as described in my previous email. If, however, it's a
bug fix or something else I think should go in a current minor branch, I'd
push the feature branch with the commits and leave it to the various RMs to
decide whether or not to merge it in. RM for Release-PHP-6.0 may decide
it's not needed but the RM for Release-PHP-6.1 decides to merge it in.
That person would then tag the next maintenance release increment as
described earlier, except in this scenario they would be the only person
with the ability to commit/merge to that branch. This way, RMs continue
having control over release branches, just as they do now, while having a
vastly improved branching model.
--Kris