On Thu, Nov 15, 2018 at 9:59 AM Nikita Popov <nikita....@gmail.com> wrote: > > 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
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
