On Fri, Nov 16, 2018 at 7:17 AM Dmitry Stogov <dmi...@zend.com> wrote: > - 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). > If fixes are not required to be merged to PHP-8, then how do we ensure that those fixes (especially the security ones) will still be in effect when 8.0 is released?
> To target typed-properties or other significant changes to PHP-7.4, it's > better to commit them before PHP-8 branching. > How will that impact deprecations? Are we calling those "not significant"? I'd actually say yeah since they tend to take the form of a few lines of "stop doing this". I do worry about our ability to pull a deprecations list together by January though. FTR; This feels like the worst available option. It's basically just early branching with bad names. I'd much sooner branch PHP-7.4 in January and have that be it. -Sara On Fri, Nov 16, 2018 at 7:17 AM Dmitry Stogov <dmi...@zend.com> wrote: > > > 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. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
