On Fri, Jul 11, 2014 at 10:29 AM, Stas Malyshev <smalys...@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=php-src.git;a=blob;f=.travis.yml;h=f1a333adcb3e6c35f3fe19c27fbd7a28d99fe7de;hb=refs/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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
