On 15.11.2018 at 17:46, Zeev Suraski wrote:

> On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker <cmbecke...@gmx.de>
> wrote:
> 
>> On 15.11.2018 at 15:27, Nikita Popov wrote:
>>
>>> Because each new branch introduces a lot of merge overhead for
>>> contributors, I would further propose that merges should only go up to
>>> PHP-7.4, while merges into master (PHP 8) will be performed occasionally,
>>> on an as-needed basis, by the people working on it.
>>
>> Have you considered having a separate PHP-8 branch, which can be rebased
>> onto master from time to time, and eventually be merged into master
>> (basically, treating the PHP-8 branch as a big feature branch)?
> 
> First, I think that continuously merging the level of changes we have in
> store for PHP 8 on an ongoing basis from a branch into master - while
> master is a moving target - would be a pretty big headache.   That's why I
> think there's sense to PHP 8 being the master branch, where most
> development would go towards.
> 
> However, I think that if PHP 8 is on master - it should become the
> responsibility of people who introduce patches for 7.4 - to also ensure
> that they work with 8 (master).  If PHP 8 will be in a branch, that's much
> less likely to happen.  Given the complexity and effort of 8, I think we
> could use some shared responsibility here, instead of putting the burden on
> the few working on the PHP 8 magic.

Actually, I'm fine with this.  What I wouldn't like is that we have a
master which is not always merged into, since that likely causes
headaches for those willing to merge their changes from PHP-7.4 upwards,
and maybe also for those testing on “nightlies”.

> Another option, by the way, would be ditching 7.4 altogether and focusing
> our efforts on 8.0 right away.  It does mean people won't get typed
> properties in 2019, but it will mean they'll likely get PHP 8 sooner.

Yeah, might still be an option, but I would have preferred to already
have had an RFC for this. :)

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to