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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
