Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1396523991.2982.340.camel@guybrush>
References: <CAMUwpuQZrHBVkipgfbtaPxwUqGBGoX=AgAJrzXWCS5GATQcsbA@mail.gmail.com>
	<CAKOpQSwZ9-NNwHMSt2rrMw7s63bxf7+NYtAeDC-F=BDy+YVXTg@mail.gmail.com>
	<1396523991.2982.340.camel@guybrush>
Date: Thu, 3 Apr 2014 04:32:53 -0700
Message-ID: <CAKOpQSw4CpaZLdB0tkeorwnO+Ax9aYqFmMYasxwRwDLok8BZZw@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b5d48800ec7b804f621c3dd
Subject: Re: [PHP-DEV] Branching PHP6
From: kris.craig@gmail.com (Kris Craig)

--047d7b5d48800ec7b804f621c3dd
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 3, 2014 at 4:19 AM, Johannes Schl=FCter <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 f=
or
> > each release.  Additionally, it also forces us to target features for o=
ne
> > 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

--047d7b5d48800ec7b804f621c3dd--