Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59225
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <op.wby3gkjqidpuyk@slws007.slhq.int>
References: <CAGa2bXZP0GfH2_D8yOtj-LvbM2tQFQ49K4RwB8max9v4cCpTxg@mail.gmail.com>
 <op.wby3gkjqidpuyk@slws007.slhq.int>
Date: Fri, 30 Mar 2012 17:22:31 +0900
Message-ID: <CAGa2bXbMr4+xfwqK+D71MZHfQ1XPOdD9tRTCuRdOunwr1uT3MQ@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Merge from 5.3 and/or 5.4. What's the current policy?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

Bug fix can be merged upwards. However,
Are we free to merge feature changes?

Adding new module constant is new feature.
I certainly would like to have it on 5.4 and it's
probably OK for 5.4, but how about 5.3?
So I'm asking procedure before commit.

Before git, we just commit new feature/changes
to trunk and we could think/argue about merge
later. Now we need to think/argue about merge,
then commit.

We need some guidelines for feature changes,
if we are going to keep "merge upward" policy.

Anyway, RM of 5.3/5.4 are okay to add module
constants to pgsql? If there is no objection, I'll
commit the change and updates docs.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

2012/3/30 Gustavo Lopes <glopes@nebm.ist.utl.pt>:
> On Fri, 30 Mar 2012 02:59:29 +0200, Yasuo Ohgaki <yohgaki@ohgaki.net> wro=
te:
>
>> Since the git work flow in the wiki requires to apply patch to
>> lowest possible =A0branch, then merge upwards.
>>
>> This changes old work flow, commit trunk, then merge to
>> release.
>>
>> I've committed simple build problem fix to all branches, I think
>> release masters don't care such merge. However, how about
>> feature changes?
>>
>> I have simple patch for
>>
>> Request #47570 =A0libpq's PG_VERSION should be exported to userland
>> https://bugs.php.net/bug.php?id=3D47570
>>
>> This is simple change, but it's new feature. (I added 2 new module
>> constants for PG_VERSION, PG_VERSION_STR)
>>
>> Question is "What's the standard work flow for new features?"
>>
>
> I don't see how this is any different. "Lowest possible branch" doesn't
> necessarily mean 5.3. It can mean 5.4 or master.
>
> If the feature is not appropriate for 5.3, but it is for 5.4 and master,
> commit it to 5.4 and merge 5.4 into master. Or it can be appropriate just
> for master, in which case there's no merge into other branches. This is t=
he
> most common scenario -- when a commit is applicable to one branch and all
> other more recent ones.
>
> The problem with the current workflow is only when you have something
> specific to a lower branch, which is not applicable to upper branches
> because the code base has diverged. You still have to merge upwards in th=
ose
> situations and resolve the likely conflict (typically with the "ours"
> strategy).
>
> --
> Gustavo Lopes