hm, I should read better... "The REQUEST_TIME value inside server now returns a floating point number"
How does it break BC except if one is doing a strong type test? which makes very little sense in this case. While a fix is easy, (int) casting and works with all previous versions, I would like to know how it breaks apps out there. On Sat, Dec 24, 2011 at 12:01 PM, Pierre Joye <pierre....@gmail.com> wrote: > hi, > > I don't remember a change about it and did not check the log yet. > Would you mind to write here how it is broken please? It could help > the discussions :) > > But yes, if it has changed in an incompatible way, I'd to go with a > revert as well. > > Cheers, > > On Sat, Dec 24, 2011 at 11:13 AM, André Rømcke <a...@ez.no> wrote: >> Hi, >> >> >> >> a bit late to the party maybe, but why was REQUEST_TIME broken in 5.4 >> instead of adding a new parameter? (like REQUEST_MICROTIME) >> Is the Release Process not followed yet? >> >> >> - x.y.z to x.y+1.z >> - (...) >> - Backward compatibility must be kept >> >> ( https://wiki.php.net/rfc/releaseprocess ) >> >> >> It is not a big deal (we are used to it), but it does break a couple of >> things in for instance eZ Publish & Zeta Components which will by the >> nature of things not be fixed before the next release. >> Most customers will hopefully make sure the version of the software they >> are using is tested/certified for php 5.4 before upgrading, but from >> experience, some will not. >> >> >> Other then that, happy xmas! > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
