Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Thu, Jan 24, 2019 at 5:11 PM Levi Morrison wrote: > On Thu, Jan 24, 2019 at 7:52 AM Nikita Popov wrote: > > > > On Fri, Nov 16, 2018 at 4:36 PM Sara Golemon wrote: > > > > > On Fri, Nov 16, 2018 at 9:26 AM Nikita Popov > wrote: > > > > I feel like there may be some understanding here, because what > > > > is proposed here seems to match exactly what you proposed > > > > in your first mail to this thread. > > > > > > > Perhaps the impedance mismatch is in calling the branch "PHP-8". > > > Calling it that says to me, "It's my responsibility to merge bugfixes > > > if I want them propagated to what will become 8.0.0-final". Calling > > > it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than > > > "8" says, "Development is happening as normal, and the feature branch > > > is the problem of the people working on the feature. > > > > > > Also, I'm going to quote again the specific language Dmitry used: > > > > > > > - 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). > > > > > > > "move" says to me "rename the branches", which again, if fixes aren't > > > being dutifully picked/merged/whatever to this branch, then they > > > inevitably will get lost. It's not that I don't trust someone working > > > on the feature branch to do their best, it's that it shouldn't be > > > their responsibility. > > > > > > -Sara > > > > > > > I'd like to bring this up again. Typed properties has been merged, so we > > currently don't have any major code changes pending. To clarify what > > exactly I'm proposing: > > > > * Create the PHP-7.4 branch now/soon, rather than in summer. > > * master will be PHP 8.0. > > * All changes are applied to the lowest applicable branch and then > merged > > up as usual, including to PHP-7.4 and master. > > * NEWS mentions for bug fixes are only added up to PHP-7.3. They are not > > added on the PHP-7.4 branch, just like for master. (Excluding changes > that > > are only in 7.4/8.0, of course.) > > * All feature additions can generally still go to the PHP-7.4 branch, > > there is no freeze. > > * Backwards incompatible changes and major internal API changes can go > to > > master (assuming they are accepted through the usual processes). > > > > Nikita > > As long as someone will help me get the covariance/contravariance > patch merged in correctly when the time comes, I'm all for it. > As the reception seems positive, I'll go ahead and create the branch now. Nikita
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Thu, Jan 24, 2019 at 7:52 AM Nikita Popov wrote: > > On Fri, Nov 16, 2018 at 4:36 PM Sara Golemon wrote: > > > On Fri, Nov 16, 2018 at 9:26 AM Nikita Popov wrote: > > > I feel like there may be some understanding here, because what > > > is proposed here seems to match exactly what you proposed > > > in your first mail to this thread. > > > > > Perhaps the impedance mismatch is in calling the branch "PHP-8". > > Calling it that says to me, "It's my responsibility to merge bugfixes > > if I want them propagated to what will become 8.0.0-final". Calling > > it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than > > "8" says, "Development is happening as normal, and the feature branch > > is the problem of the people working on the feature. > > > > Also, I'm going to quote again the specific language Dmitry used: > > > > > - 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). > > > > > "move" says to me "rename the branches", which again, if fixes aren't > > being dutifully picked/merged/whatever to this branch, then they > > inevitably will get lost. It's not that I don't trust someone working > > on the feature branch to do their best, it's that it shouldn't be > > their responsibility. > > > > -Sara > > > > I'd like to bring this up again. Typed properties has been merged, so we > currently don't have any major code changes pending. To clarify what > exactly I'm proposing: > > * Create the PHP-7.4 branch now/soon, rather than in summer. > * master will be PHP 8.0. > * All changes are applied to the lowest applicable branch and then merged > up as usual, including to PHP-7.4 and master. > * NEWS mentions for bug fixes are only added up to PHP-7.3. They are not > added on the PHP-7.4 branch, just like for master. (Excluding changes that > are only in 7.4/8.0, of course.) > * All feature additions can generally still go to the PHP-7.4 branch, > there is no freeze. > * Backwards incompatible changes and major internal API changes can go to > master (assuming they are accepted through the usual processes). > > Nikita As long as someone will help me get the covariance/contravariance patch merged in correctly when the time comes, I'm all for it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
Am 24.01.2019 um 15:52 schrieb Nikita Popov: * Create the PHP-7.4 branch now/soon, rather than in summer. * master will be PHP 8.0. * All changes are applied to the lowest applicable branch and then merged up as usual, including to PHP-7.4 and master. * NEWS mentions for bug fixes are only added up to PHP-7.3. They are not added on the PHP-7.4 branch, just like for master. (Excluding changes that are only in 7.4/8.0, of course.) * All feature additions can generally still go to the PHP-7.4 branch, there is no freeze. * Backwards incompatible changes and major internal API changes can go to master (assuming they are accepted through the usual processes). Makes sense to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On 24.01.2019 at 15:52, Nikita Popov wrote: > I'd like to bring this up again. Typed properties has been merged, so we > currently don't have any major code changes pending. To clarify what > exactly I'm proposing: > > * Create the PHP-7.4 branch now/soon, rather than in summer. > * master will be PHP 8.0. > * All changes are applied to the lowest applicable branch and then merged > up as usual, including to PHP-7.4 and master. > * NEWS mentions for bug fixes are only added up to PHP-7.3. They are not > added on the PHP-7.4 branch, just like for master. (Excluding changes that > are only in 7.4/8.0, of course.) > * All feature additions can generally still go to the PHP-7.4 branch, > there is no freeze. > * Backwards incompatible changes and major internal API changes can go to > master (assuming they are accepted through the usual processes). IMHO, a sensible compromise to allow starting real work on PHP 8 while still keeping 7.4 open for feature additions. If we do so, I wonder whether we should prepone the 7.4 RM selection. I had planned to issue a call for volunteers in early March, but maybe it would be good to have RMs available earlier to supervise the PHP-7.4 branch. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Thu, Jan 24, 2019 at 8:52 AM Nikita Popov wrote: > I'd like to bring this up again. Typed properties has been merged, so we > currently don't have any major code changes pending. To clarify what > exactly I'm proposing: > > * Create the PHP-7.4 branch now/soon, rather than in summer. > * master will be PHP 8.0. > * All changes are applied to the lowest applicable branch and then merged > up as usual, including to PHP-7.4 and master. > * NEWS mentions for bug fixes are only added up to PHP-7.3. They are not > added on the PHP-7.4 branch, just like for master. (Excluding changes that > are only in 7.4/8.0, of course.) > * All feature additions can generally still go to the PHP-7.4 branch, > there is no freeze. > * Backwards incompatible changes and major internal API changes can go to > master (assuming they are accepted through the usual processes). > > I'm on board with this. My prior objection was that the third point in your list (all changes merged to master as usual) didn't appear to be the plan during the earlier discussion. If it's the plan now, then +1 from me. I do want to clarify your comment about not being in feature freeze for 7.4. I take this to mean not just that new implementations can be landed, but that new RFCs can be put forward, voted on, approved, and merged. That comes with the understanding that large ones SHOULD target 8.0, but they don't necessarily have to. -Sara
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Fri, Nov 16, 2018 at 4:36 PM Sara Golemon wrote: > On Fri, Nov 16, 2018 at 9:26 AM Nikita Popov wrote: > > I feel like there may be some understanding here, because what > > is proposed here seems to match exactly what you proposed > > in your first mail to this thread. > > > Perhaps the impedance mismatch is in calling the branch "PHP-8". > Calling it that says to me, "It's my responsibility to merge bugfixes > if I want them propagated to what will become 8.0.0-final". Calling > it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than > "8" says, "Development is happening as normal, and the feature branch > is the problem of the people working on the feature. > > Also, I'm going to quote again the specific language Dmitry used: > > > - 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). > > > "move" says to me "rename the branches", which again, if fixes aren't > being dutifully picked/merged/whatever to this branch, then they > inevitably will get lost. It's not that I don't trust someone working > on the feature branch to do their best, it's that it shouldn't be > their responsibility. > > -Sara > I'd like to bring this up again. Typed properties has been merged, so we currently don't have any major code changes pending. To clarify what exactly I'm proposing: * Create the PHP-7.4 branch now/soon, rather than in summer. * master will be PHP 8.0. * All changes are applied to the lowest applicable branch and then merged up as usual, including to PHP-7.4 and master. * NEWS mentions for bug fixes are only added up to PHP-7.3. They are not added on the PHP-7.4 branch, just like for master. (Excluding changes that are only in 7.4/8.0, of course.) * All feature additions can generally still go to the PHP-7.4 branch, there is no freeze. * Backwards incompatible changes and major internal API changes can go to master (assuming they are accepted through the usual processes). Nikita
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Fri, Nov 16, 2018 at 9:26 AM Nikita Popov wrote: > I feel like there may be some understanding here, because what > is proposed here seems to match exactly what you proposed > in your first mail to this thread. > Perhaps the impedance mismatch is in calling the branch "PHP-8". Calling it that says to me, "It's my responsibility to merge bugfixes if I want them propagated to what will become 8.0.0-final". Calling it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than "8" says, "Development is happening as normal, and the feature branch is the problem of the people working on the feature. Also, I'm going to quote again the specific language Dmitry used: > - 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). > "move" says to me "rename the branches", which again, if fixes aren't being dutifully picked/merged/whatever to this branch, then they inevitably will get lost. It's not that I don't trust someone working on the feature branch to do their best, it's that it shouldn't be their responsibility. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Fri, Nov 16, 2018 at 4:10 PM Sara Golemon wrote: > On Fri, Nov 16, 2018 at 7:17 AM Dmitry Stogov 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? > Changes are still merged into 8.0. It's just not the responsibility of the individual contributor to merge every single commit as it is made. Instead the people working on the PHP 8 branch perform merges as needed. E.g. Dmitry has been maintaining a JIT branch for many years now, by semi-regularly merging current master into it. Basically just the way a standard long-term feature branch works. > 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. > Deprecations have to go into 7.4, there's no other option there. Creating a PHP 8 feature branch does not mean that changes (even language changes) can't be applied to PHP 7.4. It may be slightly more convenient if large changes like typed properties land before branching, but it's not a hard requirement. 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. > I feel like there may be some understanding here, because what is proposed here seems to match exactly what you proposed in your first mail to this thread. Nikita
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Fri, Nov 16, 2018 at 7:17 AM Dmitry Stogov 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 wrote: > > > On 11/15/18 10:24 PM, Nikita Popov wrote: > > On Thu, Nov 15, 2018 at 7:46 PM Sara Golemon wrote: > > > >> On Thu, Nov 15, 2018 at 10:46 AM Zeev Suraski 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. > > Than
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On 11/15/18 10:24 PM, Nikita Popov wrote: > On Thu, Nov 15, 2018 at 7:46 PM Sara Golemon wrote: > >> On Thu, Nov 15, 2018 at 10:46 AM Zeev Suraski 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.
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Thu, Nov 15, 2018 at 7:46 PM Sara Golemon wrote: > On Thu, Nov 15, 2018 at 10:46 AM Zeev Suraski 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. Nikita
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Thu, Nov 15, 2018 at 10:46 AM Zeev Suraski 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
Re: [PHP-DEV] 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 > 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
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Thu, Nov 15, 2018 at 9:59 AM Nikita Popov wrote: > > On Thu, Nov 15, 2018 at 5:46 PM Zeev Suraski wrote: > > > > > > > On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker > > wrote: > > > >> On 15.11.2018 at 15:27, Nikita Popov wrote: > >> > >> > Based on previous discussions, it appears that our current plan is to > >> > release PHP 8.0 after PHP 7.4. Normally we only branch off versions once > >> > they reach beta stage, which means the PHP-7.4 branch will only be > >> created > >> > around summer 2019. > >> > > >> > I would like to propose to branch off PHP-7.4 earlier this time and > >> start > >> > working on PHP 8.0 in the master branch. This will allow people to start > >> > working on changes that are not suitable for PHP 7.4 (due to either > >> > significant internal ABI breakage, or userland breakage). > >> > > >> > 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. > > > > If people are introducing major changes (e.g. when typed properties lands) > it's reasonable to expect that they will also carry out the merge to the > PHP 8 branch, as such merges are often tricky and require domain knowledge. > What I'm mainly suggesting is that we do not merge every single commit into > the PHP 8 branch, as is our current practice. Depending on where you land > your change, you currently already have to merge across PHP-7.1, PHP-7.2, > PHP-7.3 and master, which is a pretty big hassle. I would rather not add > one more branch to that list. > > I really don't think that merging into the PHP 8 branch is going to be an > issue, though we can always reconsider the merge procedure if that turns > out to be wrong. > > 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. > > > > For me PHP 7.4 is more important for deprecations than typed properties. If > we don't have a PHP 7.4 release, we end up in the same situation as PHP 7: > We have an opportunity to introduce a degree of BC breakage, but the last > opportunity to introduce deprecations has already sailed by the time the > decision is made. Unless we are fine with removing functionality without > prior deprecation, I think we need the PHP 7.4 release. > > Nikita I strongly agree on 7.4 being necessary. I think no matter how we do the branching we will have some headache; I will support whatever the most active committers and maintainers decide is best. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Thu, Nov 15, 2018 at 5:46 PM Zeev Suraski wrote: > > > On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker > wrote: > >> On 15.11.2018 at 15:27, Nikita Popov wrote: >> >> > Based on previous discussions, it appears that our current plan is to >> > release PHP 8.0 after PHP 7.4. Normally we only branch off versions once >> > they reach beta stage, which means the PHP-7.4 branch will only be >> created >> > around summer 2019. >> > >> > I would like to propose to branch off PHP-7.4 earlier this time and >> start >> > working on PHP 8.0 in the master branch. This will allow people to start >> > working on changes that are not suitable for PHP 7.4 (due to either >> > significant internal ABI breakage, or userland breakage). >> > >> > 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. > If people are introducing major changes (e.g. when typed properties lands) it's reasonable to expect that they will also carry out the merge to the PHP 8 branch, as such merges are often tricky and require domain knowledge. What I'm mainly suggesting is that we do not merge every single commit into the PHP 8 branch, as is our current practice. Depending on where you land your change, you currently already have to merge across PHP-7.1, PHP-7.2, PHP-7.3 and master, which is a pretty big hassle. I would rather not add one more branch to that list. I really don't think that merging into the PHP 8 branch is going to be an issue, though we can always reconsider the merge procedure if that turns out to be wrong. 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. > For me PHP 7.4 is more important for deprecations than typed properties. If we don't have a PHP 7.4 release, we end up in the same situation as PHP 7: We have an opportunity to introduce a degree of BC breakage, but the last opportunity to introduce deprecations has already sailed by the time the decision is made. Unless we are fine with removing functionality without prior deprecation, I think we need the PHP 7.4 release. Nikita
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker wrote: > On 15.11.2018 at 15:27, Nikita Popov wrote: > > > Based on previous discussions, it appears that our current plan is to > > release PHP 8.0 after PHP 7.4. Normally we only branch off versions once > > they reach beta stage, which means the PHP-7.4 branch will only be > created > > around summer 2019. > > > > I would like to propose to branch off PHP-7.4 earlier this time and start > > working on PHP 8.0 in the master branch. This will allow people to start > > working on changes that are not suitable for PHP 7.4 (due to either > > significant internal ABI breakage, or userland breakage). > > > > 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. 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. Zeev
[PHP-DEV] Re: Branch off PHP-7.4 early
On 15.11.2018 at 15:27, Nikita Popov wrote: > Based on previous discussions, it appears that our current plan is to > release PHP 8.0 after PHP 7.4. Normally we only branch off versions once > they reach beta stage, which means the PHP-7.4 branch will only be created > around summer 2019. > > I would like to propose to branch off PHP-7.4 earlier this time and start > working on PHP 8.0 in the master branch. This will allow people to start > working on changes that are not suitable for PHP 7.4 (due to either > significant internal ABI breakage, or userland breakage). > > 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)? -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
