Re: Re: Branch off PHP-7.4 early

On 15.11.2018 at 17:46, Zeev Suraski wrote: > On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker <cmbecker69@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