On 02/05/2013 12:16 PM, Karoly Negyesi wrote: >> Yup, so please test it against 5.5 now. Have you done so? It is rather >> trivial to do. Grab it from git or there is a tarball at http://qa.php.net > >>> Let me describe my world. I am working on an open source package. So >>> does another 1000 or so developers. And another 10 000 adds modules >>> (or maybe you'd call them plugins). I do not even know how many then >>> adds custom, site specific code. This whole pile of software forms an > > Care to explain how am I supposed to test all that against 5.5? > Obviously you'd need every project owner doing this but they won't > because their hosts are not even on 5.4 so why would they even think > of 5.5? (5.4? A lot of people are on 5.2.) > >> Yes, I would say it is unattainable. You are essentially asking that we >> don't make any changes. > > Where did I say that? > >> Nothing that could possibly affect existing code >> down to and including any potential warning messages even if that code >> is obviously incorrect, insecure and/or not doing what the developer >> intended. That means no new keywords, no new notices, no bug fixes. What >> exactly can we do in a new version then? > > new keywords is an interesting discussion to have -- it's actually the > first real thing to discuss as far as I can see. For example that is > something that version strings would tremendously help. You do not > need to maintain the whole lot of behaviors for every version just the > parser? Also, new keywords typically introduce new syntax. Here's an > example, a quick github code search found > https://github.com/chriso/klein.php/blob/master/klein.php#L600 this. > function yield() is not a valid usage of the new yield keyword nor is > yield() so perhaps it's not impossible to accomodate this kind of > code? Let's discuss.
Let's not. We are not going to add version tags. There is nothing to discuss here. > New error messages could be INI controlled to avoid surprises. And no, more ini switches to control the nature of notices won't happen either, sorry. > Why no bugfixes? Absolutely yes to bugfixes -- once again if a piece > was not running before then that running in a new version is breaking > *forward* not backwards compatbility. If a bugfix changes behavior, > then again, that needs discussion, do you have any good examples? I am > not familiar enough with the bugs to say "here's a bugfix which made > foo(NULL) return NULL instead of FALSE" or somesuch. Very few bug fixes are simple in the sense that they make something work that didn't work at all before. Usually they fix behaviour, generally in edge-case scenarios, but not always. Two examples from PHP 5.4: We discovered that the output of our Tiger hash was wrong. This has been corrected in 5.4. If you have stored pre-5.4 Tiger hashes you are going to need to fix these. See the comments of http://php.net/61307 for the code to generate the old hashes for upgrade purposes. The output from pack() was non-standard as well. We have brought that in line with pack() from Perl and other languages. This can potentially break code as we saw with it breaking Pear's Tar implementation. Does this mean we shouldn't fix stuff like this? I don't think it does. The way to handle it from user apps is to test your app against new versions as early as possible and to make it clear that Drupal version 7.X is fully compatible with PHP version 5.4. It may work with later versions, of course, but as a project you should test and state which versions it is guaranteed to work with. Once you have done sufficient testing with 5.5 you can certify a specific version of Drupal as being compatible with 5.5. I don't think it needs to be any more complicated than that. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
