Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73565
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Kris Craig <kris.craig@gmail.com>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
In-Reply-To: <CAKOpQSwZ9-NNwHMSt2rrMw7s63bxf7+NYtAeDC-F=BDy+YVXTg@mail.gmail.com>
References:
	 <CAMUwpuQZrHBVkipgfbtaPxwUqGBGoX=AgAJrzXWCS5GATQcsbA@mail.gmail.com>
	 <CAKOpQSwZ9-NNwHMSt2rrMw7s63bxf7+NYtAeDC-F=BDy+YVXTg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 03 Apr 2014 13:19:51 +0200
Message-ID: <1396523991.2982.340.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Branching PHP6
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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.

On the dead release branches see my message from yesterday:
http://news.php.net/php.internals/73514

> On a separate note, as alluded to in Step 2, I'd also recommend using
> feature branches instead of committing directly into the "trunk" for a
> given version.  For example, I create a LOCAL branch called "Bug_53333" off
> of "Release-PHP-6.0".  I make several commits while working on fixing this
> bug over the course of several days.  When it's done, just like with the
> Release branches, I merge the feature branch back into Release-PHP-6.0
> (using "--no-ff" to preserve the commit history and feature branch name at
> the merge point) and delete the feature branch.

This already happens for many larger changes. Most changes are small and
a single commit or are rewritten into one, though.

johannes