On Sat, Nov 22, 2014 at 2:05 AM, Lester Caine <les...@lsces.co.uk> wrote:
> On 22/11/14 09:14, Pierre Joye wrote: > > That's why I strongly suggest to make a more realistic time plan and > > stick to it. Specific dates can or should be define later but the > > period (mid october f.e.) should be defined now. One week more when it > > is about fixing one last critical bug for an existing feature is > > perfectly OK, 1 month to actually finish a new feature may not be > > good, at all. > > When a customer tells me I have to give him a completion date I have a > stock answer. 'When you sign off on the specification'. The current > problem is that we have no idea just what form PHP7 is going to take, > and no idea just how much code will need to be reworked as a result. > > There is a lot of parallel developments going on all with different > goals and in my book all at odds with a cohesive roadmap? Many people > want their pet features included ASAP but as yet there is no agreement > even on what PHP7 will be? Until there are a set of goals any planning > on time is irrelevant. > > It IS all chicken and egg since one can't know now just how long it will > take to do some of the things being discussed, and it may be that it's > impossible to achieve a preferred goal in a reasonable time frame? THAT > is basically what happened with PHP6? The selections made for the goal > turned out to be the wrong ones but it took time for people to give in > ad scrap that roadmap. > > From a user point of view I'd rather know what will NOT be part of PHP7 > early, and anything being removed will be tagged as deprecated in PHP5.7 > ... I don't see any way forward without a bridging build to help > identify code that needs work, and I would like to make a case for NOT > loading PHP7 down with compatibility switches like e_strict! Lets keep > the compatibility aspect to PHP5.7 and those of us who don't have time > to 'upgrade' will continue to run PHP5 for another 10+ years. PHP7 > should be - hopefully - a single clean interface with in my book UTF8 > capability as a bare minimum. But I don't think we need Python3 type > breaks to achieve this since much of the core has already had UTF8 > sneaked in via the back door. I'm thinking more like a C -> C++ break > where the core procedural framework still works, but people can add OO > namespaces on top which do not have to be 'required'. I just don't see > how the 'everything must be exceptions' camp can be accommodated with > procedural error handling? > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > A valid point. Perhaps, before we decide on a timeline for release, we should first decide on a timeline for acceptance of new features/etc. We should have a cut-off date for RFCs targetted for PHP 7. After that date has passed, we gather up all the stuff slated for 7.0 and figure out how long it will take. That will yield the timeline we're looking for. Voting on a release timeline before then just invites problems and confusion down the line and would probably force us to ultimately come up with a revised timeline later on, anyway. It would be better to do this by the book and establish a scope cut-off before drafting any timeline for release. Based on this, as well as flaws in the RFC itself, I'm going to have to vote no. Not because I don't support a PHP 7 release timeline, but because I don't think this RFC at this time is a responsible way to go about doing it. --Kris
