Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP 5.1 »

PHP 5.1

php.internals

Andi Gutmans

20 years ago
Hey, Just wanted to thank everyone who helped get PHP 5.1 out of the door after a lot of efforts. Special thanks to Steph who stepped up to make the upgrading guide happen. I think this should become a standard for future PHP releases. Also thanks to Ilia who picked up the last few rounds of PHP 5.1 release management to make it happen. Well done everyone! Andi

Pierre Joye

20 years ago
On Thu, 24 Nov 2005 16:15:04 -0800 andi@zend.com (Andi Gutmans) wrote:
> Hey, > > Just wanted to thank everyone who helped get PHP 5.1 out of the door > after a lot of efforts. > Special thanks to Steph who stepped up to make the upgrading guide > happen. I think this should become a standard for future PHP releases. > Also thanks to Ilia who picked up the last few rounds of PHP 5.1 > release management to make it happen. > > Well done everyone!
Well Done Derick who did again what's the hell he wants. If anyone can show me we agreed to put the crappy (yes crappy) new date object ON by default in 5.1.0. We agreed to not active it by default but let it under the experimental #ifdef so Derick can still be lazy and use the same tree to maintain his stuff. I ask to stop the realease process, put all this Object date back in the experimental #ifdef and roll 5.1 again. --Pierre

Ilia A.

20 years ago
Pierre wrote:
> On Thu, 24 Nov 2005 16:15:04 -0800 > andi@zend.com (Andi Gutmans) wrote: > > >>Hey, >> >>Just wanted to thank everyone who helped get PHP 5.1 out of the door >>after a lot of efforts. >>Special thanks to Steph who stepped up to make the upgrading guide >>happen. I think this should become a standard for future PHP releases. >>Also thanks to Ilia who picked up the last few rounds of PHP 5.1 >>release management to make it happen. >> >>Well done everyone! > > > Well Done Derick who did again what's the hell he wants.
Pierre first of all I put the change in after a discussion with Derick and a number of the while you were present btw. This was done to declare the date class for "future" proofing and allow isolation of date constants into a class, as is done for all new OO extensions.
> If anyone can show me we agreed to put the crappy (yes crappy) new date > object ON by default in 5.1.0.
I'll pretend that by "crappy" you mean limited, which it is because all the methods are disabled till 5.1.1 when we will enable them to allow a extensive test cycle. Ilia

Pierre Joye

20 years ago
On Thu, 24 Nov 2005 21:52:28 -0500 ilia@prohost.org (Ilia Alshanetsky) wrote: ^
> Pierre first of all I put the change in after a discussion with Derick > and a number of the while you were present btw. This was done to > declare the date class for "future" proofing and allow isolation of > date constants into a class, as is done for all new OO extensions.
You cannot trust Derick about ext/date, sorry. He did not respect our decisions since he started to work on the TZ support and force anyone to use the new implementation in 5.1.x. I never agreed to anything Derick did in 5.x but was forced to shut up and let him put some stupid object inside a #ifdef, as far as this crap was in a #ifdef, yes I would have said, fine, we have time until php6.
> I'll pretend that by "crappy" you mean limited, which it is because > all the methods are disabled till 5.1.1 when we will enable them to > allow a extensive test cycle.
It is crap, I need one hour to do it and I doubt Derick has any good plan about a real new Date object API in php But this is _not_ the problem, and you know that. --Pierre

Rasmus Lerdorf

20 years ago
Pierre, I agree with you that it was a bad idea to turn on the stub date class in the final release candidate giving people less than a week to notice that we now conflict with a common pear class. We get all the breakage and none of the benefits and nobody had any time to prepare the pear side of the house for this. It also sucks that not a single pear person tested the final RC and brought this up in the past week. There is plenty of blame to go around here. Longer term we have to be able to move functionality from pear to php. That's one of the reasons pear exists. You can argue all you want over whose date implementation is better. In the end code speaks. I know you don't want to write any code unless you are sure it will be the chosen implementation, and I don't think you ever managed to convince everyone of the $date->m++ style of date manipulation. Not that this really matters, in the end what matters is actual working code. We will choose inferior working code over the perfect half-finished implementation every time. So, if as you say it will only take you an hour to implement, please do it so we can try it. -Rasmus Pierre wrote:

Pierre Joye

20 years ago
On Thu, 24 Nov 2005 21:23:17 -0800 rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
> Pierre, I agree with you that it was a bad idea to turn on the stub > date class in the final release candidate giving people less than a > week to notice that we now conflict with a common pear class. We get > all the breakage and none of the benefits and nobody had any time to > prepare the pear side of the house for this. It also sucks that not > a single pear person tested the final RC and brought this up in the > past week. There is plenty of blame to go around here.
No, do not blame anyone but the one who commited the change and the one who agreed. Do not expect me neither to come up with any complaints, you know how it ends when I try.
> Longer term we have to be able to move functionality from pear to > php. That's one of the reasons pear exists. You can argue all you > want over whose date implementation is better. In the end code > speaks.
Wrong, in the end the one who commits without giving a single shit to anyone wins, in this case, Derick. You can argue or say all rethoric you have about code, commits, contribution or cooperation, facts are that from day #1 the game is biased. If I did not ask and simply commit my code in 5.0 branche, It would have gave two possible things: - I lost my karma - my code will be already in 5.0 Conclusion? I have to be an ass and do what I want, not what other could expect.
> I know you don't want to write any code unless you are sure > it will be the chosen implementation, and I don't think you ever > managed to convince everyone of the $date->m++ style of date > manipulation.
I proposed, I convinced people (read the archive if you do not remember), but my way was too nice and slow for Derick.
> Not that this really matters, in the end what matters > is actual working code. We will choose inferior working code over > the perfect half-finished implementation every time. So, if as you > say it will only take you an hour to implement, please do it so we > can try it.
What I say it is I need one hour to implement a brain dead OO interface like this one around this API. And what really matters anyway? --Pierre

Alan Knowles

20 years ago
This one's a bit more annoying than usual ;) It will basically break application that depends on the Date package (eg. most of my code as DataObjects uses it internally).. Do we really need another barrier to upgrade to 5.*? Regards Alan On Fri, 2005-11-25 at 07:55 +0100, Pierre wrote:

Helgi Þormar

20 years ago
On Fri, 25 Nov 2005 15:16:43 +0800, Alan Knowles wrote:
> This one's a bit more annoying than usual ;) > > It will basically break application that depends on the Date package > (eg. most of my code as DataObjects uses it internally).. Do we really > need another barrier to upgrade to 5.*?
Yeah indeed, now I'll have a heap of a time when my customers want to upgrade to PHP 5.1, I find it a bit odd to have this kind of breakage ... didn't we have similar situation with PEAR::File and the SPL::File ? Which was later renamed to FileObject so both could happily live side by side ? (or is my memory failing me) IMHO this should be rolled back in .1 and only introduced in PHP 6 (on by default) Rasmus mentioned that no PEAR person tested the final RC and all that and thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that change done between the final RC and the official release ? Regards Helgi

Rasmus Lerdorf

20 years ago
Helgi Þormar wrote:
> Rasmus mentioned that no PEAR person tested the final RC and all that and > thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that > change done between the final RC and the official release ?
Nope, this change was in RC6: http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u I missed it too, but then I don't use pear/Date anywhere. -Rasmus

Pierre Joye

20 years ago
On Thu, 24 Nov 2005 23:45:45 -0800 rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
> Helgi Þormar wrote: > > Rasmus mentioned that no PEAR person tested the final RC and all > > that and thus this issue wasn't found ... Correct me if I'm wrong, > > but wasn't that change done between the final RC and the official > > release ? > > Nope, this change was in RC6: > > http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u > > I missed it too, but then I don't use pear/Date anywhere.
It is not only about date, such changes in 5.1 are the worst idea we can have, and doing so late in the release process is even worst. Wez and you told me that I do propose solutions, for the 5.1 release, I see 2 possibilities: 1) Drop this 5.1.0 release and repack everything without the class date 2) Release 5.1.0pl1 as soon as possible to fix the problem 1) is, as far as I know, not possible, so we have to go with 2). Marcus, arguing such way is missing the minimum informations one may need to comment this problem. Can you seriously think that adding such class in a minor release is the way to go? What is obvious is that there is not enough people having a real influence on what should go in or what should not go. As a reminder, the last releases with such non obvious breaks was our last two... I let you wonder who wrote the fix. About ext/date, it was a bad idea from day #1 to do it this way. I proposed to add a new date/time APIs in php5 before it was even available, a 1st proposal was done and the 1st codebase was commited in pecl (where all new codes should first go for tests and approbations). I asked for feedbacks and for people willing to help to define a clean api and how it should work (both for OO and procedural). Then Derick asked me to stop to work on this extension until he is ready with the rewrite of strtotime with a new TZ, it was his only idea, for what he said. We first agreed first to do nothing in 5.1, it was too late as 5.1 was already in a bug fixes only period, who cares? he commited and replace strtotime... Then comes the replacement of date() and some other functions, and now the addition of a date """object""". Can we really say it is a mistake? a lack of attention from QA people? from users? from PEAR? I do not think so. --Pierre

Marco Kaiser

20 years ago
Hi Rasmus,
> Nope, this change was in RC6: > > http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u > > I missed it too, but then I don't use pear/Date anywhere.
thats nice to know, but RC's are Release Candidates and i understand thats not allowed to implement new features in a release process. So why does anyone changed something so important here without inform the QA list about this? I what both lists, internal, and QA and i can't check every commit to verify thats nothing changed that could break BC. I agree with Marcus that we should asap release a pl1 or 5.1.1.
-- Marco Kaiser

Marcus Börger

20 years ago
Hello Helgi, obviously one problem is that PEAR does ignore coding standards. Classes should be prefixed in both pear and core. And neither Date nor File is in any way prefixed. In th end all we see here is that we want namespaces asap. One thing to discuss now is whether we want to put out 5.1.1 or even 5.1.0pl1 asap with Date in ext/Date renamed to something diferent. best regards marcus Friday, November 25, 2005, 8:40:47 AM, you wrote:
> On Fri, 25 Nov 2005 15:16:43 +0800, Alan Knowles wrote:
>> This one's a bit more annoying than usual ;) >> >> It will basically break application that depends on the Date package >> (eg. most of my code as DataObjects uses it internally).. Do we really >> need another barrier to upgrade to 5.*?
> Yeah indeed, now I'll have a heap of a time when my customers want to > upgrade to PHP 5.1, I find it a bit odd to have this kind of breakage ... > didn't we have similar situation with PEAR::File and the SPL::File ? Which > was later renamed to FileObject so both could happily live side by side ? > (or is my memory failing me)
> IMHO this should be rolled back in .1 and only introduced in PHP 6 (on by > default)
> Rasmus mentioned that no PEAR person tested the final RC and all that and > thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that > change done between the final RC and the official release ?
> Regards > Helgi
Best regards, Marcus

Jessie Hernandez

20 years ago
Marcus, I have good news on this (I added both constants and function support!). I will post the patch soon. There are still a few things that need to be discussed, but right now the functionality is a huge step forward. Best regards, Jessie Marcus Boerger wrote:

Lukas Smith

20 years ago
Marcus Boerger wrote:
> obviously one problem is that PEAR does ignore coding standards. Classes > should be prefixed in both pear and core. And neither Date nor File is in > any way prefixed. In th end all we see here is that we want namespaces asap.
Err, how are we supposed to prefix PEAR::Date? PEAR_Date? Date_Date? Lala_Date? I guess only the first one is somewhat valid proposal. Anyways it makes absolute sense to use the best most clear class names when we add functionality currently missing in PHP. Just as well it makes sense for php core to do the same thing. The problem is just that PEAR is not part of the php development cycle. So whatever API we come up with is totally ignored by php core. This may be because the PEAR API sucks. It may also be caused by the fact that usually our implementation will probably be written for a previous PHP version. In a perfect world we would define an API, implement it in PEAR as a testbed for interest and if we find its popular and there are significant performance improvements to expect from an implementation in C we take that API and implement it in C. However I do not see this happening ever. So I do not see a point in PEAR packages claiming away nice and clear names from php core. We should either cooperate on the API level or just have php core superseed PEAR stuff. PEAR then goes and fixes whatever breakage occurs. What however would be nice is some advance notice. And where is the entry in the upgrading guide? Oh and for the record if there is a PEAR class by the name of Date you can be sure that there is a class by the name of Date as well. So in conclusion its needlessly messy. I am sure other projects than PEAR also have a Date class. Maybe we need to teach our users (including PEAR) that they should simply stick to prefixing everything with 3-4 letter combinations (maybe even offer a central place to register them, like we should do in the PEAR channel listing - http://pear.php.net/channels/). regards, Lukas

Derick Rethans

20 years ago
On Fri, 25 Nov 2005, Marcus Boerger wrote:
> Hello Helgi, > > obviously one problem is that PEAR does ignore coding standards. Classes > should be prefixed in both pear and core. And neither Date nor File is in > any way prefixed. In th end all we see here is that we want namespaces asap. > > One thing to discuss now is whether we want to put out 5.1.1 or even > 5.1.0pl1 asap with Date in ext/Date renamed to something diferent.
No, as this breaks backwards compability. I have code written for this and that is going to be released. If the class constants are removed, you will break code that is out there. There were similar reasons why Wez didn't want to change the odd PDO method because people were running it production while PDO was not even beta - which is fine. But you can definitely not change code in a released version. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Greg Beaver

20 years ago
Marcus Boerger wrote:
> Hello Helgi, > > obviously one problem is that PEAR does ignore coding standards. Classes > should be prefixed in both pear and core. And neither Date nor File is in > any way prefixed. In th end all we see here is that we want namespaces asap.
I absolutely agree with these points. It is also worth noting that the coding standards of prefixing classes were introduced long after packages like "Date" existed. We have a case of a userbase and a shifting foundation that is PHP. Perhaps the best future of PEAR is to design with those shifting sands in mind as more of a primary design concern. There's plenty of time before PHP 6, so we can get this taken care of by then, I think. These are just preliminary thoughts, but it is imperative that all PEAR classes be tested, and by inference testable, with PHP releases. Anything that comes from .php.net should work with PHP, or at least be given a chance to fix the problem before the release. This means a tighter integration of PEAR developers and PHP internals, by no means an easy task, as is shown by Pierre's tribulations over Date. At the least, it would make sense to provide some kind of PEAR-related RC cycle for PHP releases. I will see if I can shake up some ideas on how to get PEAR more involved (at least better involved) in the PHP release process over on pear-dev and report back. Greg

Oliver Grätz

20 years ago
Helgi Þormar schrieb:
> Yeah indeed, now I'll have a heap of a time when my customers want to > upgrade to PHP 5.1, I find it a bit odd to have this kind of breakage ... > didn't we have similar situation with PEAR::File and the SPL::File ? Which > was later renamed to FileObject so both could happily live side by side ? > (or is my memory failing me)
Just two cents from a user's point of view: If you had put all the time you invested in this flame war about ONE class into already introducing namespaces (e.g. Core\Date or Core:Date or Core::Date, with a notev that I hate the \ syntax) with 5.1.0, it could have been in there already. And If you needed one more convincing argument pro namespaces: Read this thread all over again! OLLi ____________ Bug? That's not a bug, that's a feature. [T. John Wendel]

Ian P. Christian

20 years ago
On Friday 25 November 2005 12:25, Oliver Grätz wrote:
> Just two cents from a user's point of view: If you had put all the time > you invested in this flame war about ONE class into already introducing > namespaces (e.g. Core\Date or Core:Date or Core::Date, with a notev that > I hate the \ syntax) with 5.1.0, it could have been in there already.
I can't help but add that I couldn't agree more. This would not have been a problem if namespaces we planned for inclusion in PHP6, and this data change was held back till then. PEAR could be moved to it's own namespace... import net.php.pear.date; For example. Also, with you 100% on the \ syntax. Jessie and others - keep up the good work. As a side note, where is the offical roadmap for the PHP project? what's the nice easy to follow tables that show what features are being planned for future relases and the current state of these features, and who's working on them? If you're not sure what I mean, take a look at how KDE does what's called 'project management' eg: a features plan, where users would have seen that date is forthcoming http://developer.kde.org/development-versions/kde-3.5-features.html and a nice, clearly formatted release schedue, with ETAs for code. http://developer.kde.org/development-versions/kde-3.5-release-plan.html
-- Ian P. Christian ~ http://pookey.co.uk

Lester Caine

20 years ago
Rasmus Lerdorf wrote:
> Pierre, I agree with you that it was a bad idea to turn on the stub date > class in the final release candidate giving people less than a week to > notice that we now conflict with a common pear class. We get all the > breakage and none of the benefits and nobody had any time to prepare the > pear side of the house for this. It also sucks that not a single pear > person tested the final RC and brought this up in the past week. There > is plenty of blame to go around here.
Rasmus - the main problem here is that there is *TOO* much going on with PHP and while everything can be justified it is just adding to the *NON* take up of PHP5! PHP5 needs a *STABLE* code base so we can convince people that PHP4 is dead and stop adding functionality to that. At the same time many of us need PHP6 *NOW* just for the Unicode stuff. There are too many cooks at the moment, so many of us who used to download a new version and run it have switched off. I do not plan to run 5.1 in production because I've only JUST got 5.0.5 stable and I don't want yet another round of tweaking hidden bugs ( I use my OWN date/time stuff ! ). I'll wait for PHP6 now before I switch again since PHP5.0.5 is stable for me !!! and if users want to use my code with the latest PHP4.4 they can fix the pigging bugs themselves :) The one thing that needs to happen is a roadmap that actually plans a single stable code base that we can all use in production and that does not tread on everybody elses toes with every release. Has *NOBODY* learnt that "It was wrong so we fixed it" is only acceptable if there is a clean path to advising users how to fix things and not simply hide all the now broken code behind messages? While plowing forward in an attempt to add lots of extra wiz bang features Microsoft like may seem essential, we end up with the same problems - how many people still use W95 ;) Rather than work on a PHP4 fork, how about a means of converting PHP4 code so it will work on PHP5, and when something needs fixing in PHP5 check and warn rather than break? If you want more of us to test RC's you need to restore confidence that it's worth the effort :(
-- Lester Caine ----------------------------- L.S.Caine Electronic Services Treasurer - Firebird Foundation Inc.

Rasmus Lerdorf

20 years ago
Lester Caine wrote:
> Rather than work on a PHP4 fork, how about a means of converting PHP4 > code so it will work on PHP5, and when something needs fixing in PHP5 > check and warn rather than break? If you want more of us to test RC's > you need to restore confidence that it's worth the effort :(
This particular issue has nothing to do with PHP 4. As far as everyone agreeing on a single release/code base. I don't see that happening. We are all on different timelines here with different requirements. I skipped PHP 5.0.x completely, for example, and will move everything to PHP 5.1 because it fit my schedule best and the performance and features in 5.1 meet my requirements. You decided on PHP 5.0.5. And we are not a software company building software for our customers here. We are all customers who happen to have similar requirements and collaborate, for better or worse, on a unified approach to meeting these requirements. As these requirements diverge with the larger customer-base it becomes harder and harder to coordinate, but I don't see how we can massage the situation to get everyone on the same page without alienating pretty much everyone. We have to find the balance between meeting the stability requirements for the customers who are perfectly happy with the featureset in PHP 4.x and don't want anything to change, the folks who want the simpler XML handling, SOAP and stronger OO in PHP 5 and then the group that need full Unicode support yesterday. We have a proposed roadmap for PHP 6 in terms of features and changes. There are no dates on that roadmap because frankly that is impossible to do in a project like this. -Rasmus

Lester Caine

20 years ago
Rasmus Lerdorf wrote:
> We have to find the balance > between meeting the stability requirements for the customers who are > perfectly happy with the featureset in PHP 4.x and don't want anything > to change, the folks who want the simpler XML handling, SOAP and > stronger OO in PHP 5 and then the group that need full Unicode support > yesterday.
I'd be happy with that if the same people who claim to be happy with PHP4 did not complain when code I've produced for PHP5 and provide open sourced does not run for them - even given that most of the Firebird stuff was never back ported to PHP4 anyway! (Which is why I've never used PHP4 in production either)
> We have a proposed roadmap for PHP 6 in terms of features and changes. > There are no dates on that roadmap because frankly that is impossible to > do in a project like this.
That is one I am following with interest, and I have a large archive of unicode data ready to apply to the results :) But *PLEASE* can we have windows builds to play with from time to time ;) Some of us still do not have the tools to build one ourselves :(
-- Lester Caine ----------------------------- L.S.Caine Electronic Services Treasurer - Firebird Foundation Inc.

Tim Van Wassenhove

20 years ago
On 2005-11-25, Lester Caine <lester@lsces.co.uk> wrote:
> That is one I am following with interest, and I have a large archive of > unicode data ready to apply to the results :) But *PLEASE* can we have > windows builds to play with from time to time ;) Some of us still do not > have the tools to build one ourselves :(
It seems microsoft gives you these tools for free nowadays: http://msdn.microsoft.com/visualc/vctoolkit2003/
-- Met vriendelijke groeten, Tim Van Wassenhove <http://timvw.madoka.be>

Jared Williams

20 years ago
Hi, As a QFE, does changing ini setting disable_class to include date fix this? Appears can declare a date class fine. Jared

Jared Williams

20 years ago
> Hi, > > As a QFE, does changing ini setting disable_class to include > date fix this? Appears can declare a date class fine. >
Er, I meant disable_classes of course ;) Jared

Oliver Grätz

20 years ago
Rasmus Lerdorf schrieb:
> Pierre, I agree with you that it was a bad idea to turn on the stub date > class in the final release candidate giving people less than a week to > notice that we now conflict with a common pear class. We get all the > breakage and none of the benefits and nobody had any time to prepare the > pear side of the house for this. It also sucks that not a single pear > person tested the final RC and brought this up in the past week. There > is plenty of blame to go around here.
Less than a week? OK; I'm just a private programmer and not from the PEAR team. I am not compiling my own PHP, I use Debian with the ~dexter builds. I got my RC6 YESTERDAY! And it breaks my code. I would have commented on this but just minutes later I learned that 5.1.0 had been released. Five minutes notice, now that's tight schedule. OLLi