Call it FUD if you like; I call it "sleeping easier at night". Like it or not, PHP is big enough now that these things have become critical points for larger businesses. To completely replace the default implementation of a core function with something new is quite a risk when it's not had enough QA. Take a look at Streams for example; things are still settling down there from their (embarrasingly buggy) 4.3 debut.
You could argue that date/time support in PHP is more critical than streams, and so changing that worries me more. Whether we intend PHP 5.1 to be a bugfix release or not isn't really relevant; people will assume that PHP 5.1 is "PHP 5 with some things fixed and some new things added"... and isn't that really what our versioning scheme says it will be too? We're a big enough project to have a responsibility (http://netevil.org/node.php?nid=427) to our users. Progress isn't about breaking BC at every turn; take a look at the Solaris approach: innovate by creating new APIs and ensure stability by preserving existing APIs. This is a solid, reliable approach to software development, and improves the quality of sleep for us, people developing applications with PHP, people paying for PHP applications and for people using those "critical" applications (banking, travel, auctions). --Wez. On 9/29/05, Jani Taskinen <[EMAIL PROTECTED]> wrote: > > The "masses" don't have to update. The old broken date() is still > in PHP 4.4.0 and PHP 5.0.x. > > Please stop the BC fud, this is not about a bugfix release but > something a bit bigger thing. > > One other solution: we can always change PHP_5_1 to PHP_6 > and do all other nice "BC" breaks too while we're at it.. > And start calling HEAD PHP 7.0 =) > > --Jani > > > On Wed, 28 Sep 2005, Wez Furlong wrote: > > > > > I agree; date() in 5.1 should default to the older "broken" code for > > BC and have a toggle for the new stuff. We could also issue a > > deprecation notice to warn people about a future move to the new code > > in PHP 6. > > > > This way we get the "best" of both worlds; BC is preserved for the > > masses of existing code and we get more QA on the new implementation > > ready for going production with the new code in PHP 6. > > > > --Wez. > > > > On 9/28/05, Andi Gutmans <[EMAIL PROTECTED]> wrote: > >> When I agreed to commit this for PHP 5.1, Derick promised that this > >> was going to completely keep BC. That is obviously not happening. > >> While I appreciate his efforts, I think as with the reference change, > >> this will cause much more widespread pain than we can even imagine. > >> Without being an expert on this timezone stuff, I suggest to have the > >> ability to get the old behavior, wether it's reverting to the system > >> date, either if we can't find the timezone entry, or if that is a > >> problem due to overlaps, then have a setting which allows to get the > >> old behavior. I don't even mind if it's called > >> date.old_broken_timezone_behavior. We did something similar in oci8 > >> in order not to break apps. > >> > >> Andi > >> > >> At 09:01 AM 9/28/2005, Rasmus Lerdorf wrote: > >>> This discussion has been interesting. ;) > >>> > >>> These sorts of problems have come up many times during the course of PHP > >>> development. Things that were implemented to solve a very specific > >>> local problem ended up causing grief when the scope of PHP grew. Think > >>> of things like magic_quotes_gpc and case-insensitive function names. > >>> Both of these actually made perfect sense when they were implemented but > >>> as things got bigger they started to get in the way and today most > >>> people wish we had broken backwards compatibility a long time ago and > >>> gotten rid of those early on. > >>> > >>> We have tended towards not breaking BC over the years leaving quite a > >>> bit of cruft around for people to deal with. Watching Derick try to > >>> buck that trend has been fun and I think he deserves a bit less vitriol > >>> for his efforts. > >>> > >>> His new date() code is obviously better and more portable than what we > >>> had. So it comes down to a pretty simple decision that doesn't need all > >>> that much emotion poured into it: > >>> > >>> Do we take the BC hit now to get clean and consistent date/time > >>> handling or do we stay with the BC over all else path we usually > >>> take? Either way we have pain. If we break BC there will be plenty > >>> of pain from very vocal users who feel personally wronged that we broke > >>> their code, and if we don't break BC and go with two different > >>> date/time systems we have to live with these two systems forever and > >>> it we will need to hold up the 5.1 release for a couple of weeks. > >>> > >>> I actually lean more towards the keeping BC side here but was hoping the > >>> new date implementation could get to the point of minimal BC breakage or > >>> perhaps even none with some sort of compatibility mode. I think there > >>> is a lot to be said for not having two different implementations so for > >>> the folks who feel so strongly about this, pitch in with some testing > >>> and help make this new implementation backward compatible. It should be > >>> possible to get this timezone mapping to the point where it addresses > >>> the majority of timezone name overlaps in the world. > >>> > >>> -Rasmus > >>> > >>> -- > >>> PHP Internals - PHP Runtime Development Mailing List > >>> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > >> Zend/PHP Conference & Expo > >> Power Your Business with PHP > >> October 18-21, 2005 - San Francisco > >> http://zend.kbconferences.com/ > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > > > -- > Donate @ <http://pecl.php.net/wishlist.php/sniper> > Disclaimer: Donating money may make me happier and friendlier for a limited > period! > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
