Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75368
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53BFA075.9000201@sugarcrm.com>
References: <2264B27B-F9BE-4540-AD1C-5046143F18D2@gmail.com>
	<CAH-PCH6bDLvEdcSH-Vt7WkDs8WHfqhghUoW55bG2zaesNSOg6w@mail.gmail.com>
	<53BFA075.9000201@sugarcrm.com>
Date: Fri, 11 Jul 2014 10:39:26 +0200
Message-ID: <CAH-PCH4mH5LDGZ2SJu7YEQytw8E6WAKwM4bFZ-6NPa4D5LDgdA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Tjerk Meesters <tjerk.meesters@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01538d50042c9304fde6e144
Subject: Re: [PHP-DEV] Travis CI for pull requests
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e01538d50042c9304fde6e144
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 11, 2014 at 10:29 AM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> > And while I was trying to figure out what does that mean, or why should
> > that prevent the travis build, I've just remembered that we don't allow
> > travis builds for PHP-5.3 and PHP-5.4 branches:
> >
> http://git.php.net/?p=3Dphp-src.git;a=3Dblob;f=3D.travis.yml;h=3Df1a333ad=
cb3e6c35f3fe19c27fbd7a28d99fe7de;hb=3Drefs/heads/PHP-5.4
> > So probably it is because of that.
>
> All feature pulls should be done against master only. They will be
> merged to appropriate branch but as pulls it should always be master
> unless it is a fix specific to particular version.
>

Theoretically you are right, that until a PR is merged, one cannot be sure
which branch will it end up in.
But I don't think we have an official rule about that this (albeit you
mentioned a few times now), and I think this will cause a significant
amount of pain for the people who wanna merge pull requests after the phpng
(or other similar major rewrite) is merged to the master, as they will be
required to backport the changes.
Ofc. when we have a diverging master we can't really save the porting, but
we could offload that work to the PR authors, and porting forward is better
documented (UPGRADING.INTERNALS) than porting backwards.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e01538d50042c9304fde6e144--