Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58562
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
Received-SPF: pass (google.com: domain of jeremiah.dodds@gmail.com designates 10.68.244.105 as permitted sender) client-ip=10.68.244.105;
To: internals@lists.php.net
References: <slrnjl54vo.mfm.dsp@experimentalworks.net>
	<CAKOpQSzFq9ZeJRk43Wj2enF2f0g6gdRxT0d25h=KTsH0V4w9xg@mail.gmail.com>
Date: Sun, 04 Mar 2012 02:53:38 -0500
In-Reply-To: <CAKOpQSzFq9ZeJRk43Wj2enF2f0g6gdRxT0d25h=KTsH0V4w9xg@mail.gmail.com>
	(Kris Craig's message of "Sat, 3 Mar 2012 15:24:01 -0800")
Message-ID: <87zkbwby4d.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PHP-DEV] Git Migration: Status Update
From: jeremiah.dodds@gmail.com

Kris Craig <kris.craig@gmail.com> writes:

> Thanks for the update!
>
> Quick question:  As far as the branching model goes, are we going to stick
> with the SVN-style of just having a branch for each release version and
> dumping all the commits directly onto it, or do you plan on switching to a
> more modern Git-style branching model of merging feature sub-branches into
> the parent version branches?  Or has this issue not been discussed yet?
>
> --Kris
>
>
> On Sat, Mar 3, 2012 at 1:58 PM, David Soria Parra <dsp@php.net> wrote:
>

The "idiomatic" way to do this would be to have releases done as tags
off of the master branch. Other than that, it makes a lot of sense to
have a branch for major features / versions, and for people to develop
specific features in their own branch, to rebase changes coming from
parent branches onto working branches, and then to merge those into
their respective parent branches after they're done.

I swear that sounds much more complicated than it is. I personally think
that php as a whole would *greatly* benefit from adopting this sort of
development model -- it's likely that git-savvy new contributors will
anyhow, and it makes accepting contributions a hell of a lot less
painful.