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
