On 11/15/18 10:24 PM, Nikita Popov wrote: > On Thu, Nov 15, 2018 at 7:46 PM Sara Golemon <poll...@php.net> wrote: > >> On Thu, Nov 15, 2018 at 10:46 AM Zeev Suraski <z...@php.net> wrote: >>> 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. >>> >> Okay, that's a fair argument against the feature branch route. >> >>> 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. >>> >> Yes to shared responsibility, no to failing to merge changes to 7.4 up >> to master. Either we will want that change, in case it should be >> merged immediately rather than kicking the can down the road, or it >> does not belong on master and we should null-merge it like we would >> any other bugfix today. We must not put ourselves in the position of >> 7.4 being ahead of master. Period. >> >>> 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. >>> >> As tempting as that may be, I think this would be incredibly >> irresponsible to PHP users. 7.4 is a necessity on the grounds of >> having a deprecations release alone, nevermind the availability of new >> features. >> >> TLDR; >> I'm willing to embrace an early fork for 7.4, but we treat it like a >> normal fork, not a special-psuedo-feature-branch. I also strongly >> oppose dropping 7.4 as a release. >> >> -Sara >> > I'm not sure how we got to 7.4 becoming a feature branch. The options as I > see it are: > > 1) Fork PHP-7.4, make master PHP 8 and merge all commits up to master. > Likely means that many commits that could target 7.4 will be going into > master, because we really can't be bothered. > 2) Keep PHP 7.4 on master and feature branch PHP-8.0-Preview, without > merging every commit. Everything that's not PHP 8 specific continues to > land on master and targets PHP 7.4. > > Both are sensible options, it depends on whether we want to focus > development on PHP 8.0 (first option) or PHP 7.4 (second option) at this > point in time. My vote goes to 2) for now. We should have a place for PHP 8 > changes now, but with the release still being at least two years away I > don't think it should become our primary development branch just yet.
hi, After all, and despite of the first proposal was mine, now I think, we should start from the second option. - in the near future (by mid January) fork PHP-8 and start active development there. Keep PHP-7.4 development in master, and don't require committers to merge into PHP-8, but restrict PHP-7.4 for minor changes or features that won't significantly affect PHP-8 branch. - in May/June move master into PHP-7.4, make PHP-8 to be master and require committers to work on master and backport changes (according to usual PHP/GIT workflow). To target typed-properties or other significant changes to PHP-7.4, it's better to commit them before PHP-8 branching. Thanks. Dmitry.
