On Thu, Nov 15, 2018 at 5:46 PM Zeev Suraski <z...@php.net> wrote: > > > On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker <cmbecke...@gmx.de> > 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
