Re: [SPAM?]: Re: [PHP-DEV] mysqli tests breaking
Am 02.09.2011 20:27, schrieb Stas Malyshev: On 9/2/11 11:03 AM, Ulf Wendel wrote: please, always test against the latest and greatest. Otherwise you'll be testing against libmysql versions that are not going to see any updates. 5.1 is still a supported version of Mysql. It is run on many production servers, so I think we must support it - it's no use to run tests on the Stas, I'm not arguing about test portability or the like. All I'm after is the counterpart to the checkbox entry Try a snapshot (PHP x.y) (Feedback), as found at bugs.php.net :-). This is no more than a friendly request to check against latest and greatest to avoid hitting bugs already fixed in libmysql. Latest GA is 5.1.58, if I'm not mistaken, http://dev.mysql.com/downloads/mysql/5.1.html . You are testing again 5.1.4x. Generally speaking, libmysql 5.1.4x won't see updates, just like PHP 5.2 won't. Regarding test portability ... you probably can imagine how annoyed I have been when orginally writing tests and hitting non portable stuff, deperately trying to actually test for something. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [SPAM?]: Re: [PHP-DEV] mysqli tests breaking
Hi! On 9/2/11 12:11 PM, Ulf Wendel wrote: This is no more than a friendly request to check against latest and greatest to avoid hitting bugs already fixed in libmysql. Latest GA is 5.1.58, if I'm not mistaken, http://dev.mysql.com/downloads/mysql/5.1.html . You are testing again 5.1.4x. Generally speaking, libmysql 5.1.4x won't see updates, just like PHP 5.2 won't. While it is a good advice in general, I seriously doubt the semantics of mysql_num_rows() or last_insert_id() SQL statement changed between 5.1.4x and 5.1.5x. That would be serious and profound change totally inaproppriate for such version and my quick check of the changelogs suggests nothing of the sort. So I'm afraid there's little hope that the failures I am observing are caused by not using 5.1.5x. Regarding test portability ... you probably can imagine how annoyed I have been when orginally writing tests and hitting non portable stuff, deperately trying to actually test for something. I agree it is annoying, but we have to sort it out nevertheless. If we have tests that work only on some specific versions and break on others, we need either to identify breakage point and have them specifically pointed out (such as: This test won't work on versions before X.Y.Z because mysql_foo_bar() function returns wrong value in foobar structure) and if possible, skipped out with informative message. Otherwise for any user that doesn't run exactly the same library version as test developer ran, the test suite doesn't work - he doesn't have the means to identify if something is wrong or not. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [SPAM?]: Re: [SPAM?]: Re: [PHP-DEV] mysqli tests breaking
Am 02.09.2011 22:07, schrieb Stas Malyshev: Hi! On 9/2/11 12:11 PM, Ulf Wendel wrote: This is no more than a friendly request to check against latest and greatest to avoid hitting bugs already fixed in libmysql. Latest GA is 5.1.58, if I'm not mistaken, http://dev.mysql.com/downloads/mysql/5.1.html . You are testing again 5.1.4x. Generally speaking, libmysql 5.1.4x won't see updates, just like PHP 5.2 won't. While it is a good advice in general, I seriously doubt the semantics of mysql_num_rows() or last_insert_id() SQL statement changed between 5.1.4x and 5.1.5x. That would be serious and profound change totally inaproppriate for such version and my quick check of the changelogs suggests nothing of the sort. So I'm afraid there's little hope that the failures I am observing are caused by not using 5.1.5x. Stas, aren't we going a little too far here in our discussion? We agree on the basic points. I'm not saying that your issues shall be ignored nor am I saying tests shall not be made portable. (But I won't spend my weekend looking into them right now ;-); I have intentionally not replied to that part of your mail.) Being someone who has been forced to write many mysqli tests in the past I lost trust in changelogs and the like. Take https://bugs.php.net/bug.php?id=55001 from today. Shortly after my bug comment, a C variant of it has been checked on four platforms against six libmysql versions to dig it down for a mysql.com bug report. My 5.1.4x is not affected, someone else 5.1.4x is. I can't reproduce with 5.1.5, others can. Fun. Regarding test portability ... you probably can imagine how annoyed I have been when orginally writing tests and hitting non portable stuff, deperately trying to actually test for something. I agree it is annoying, but we have to sort it out nevertheless. If we have tests that work only on some specific versions and break on others, we need either to identify breakage point and have them specifically pointed out (such as: This test won't work on versions before X.Y.Z because mysql_foo_bar() function returns wrong value in foobar structure) and if possible, skipped out with informative message. Argument taken. However, I'm afraid, we'll always see such things happen if any PHP extension depends on any external entity - be it a library or a database server. My thinking is that any such test issue should be handled as a day-to-day task. A task not only perfomed the week before a beta release. Any user should do the test run any time. You'd probably sign that. Need I say more, did I get your arguments? Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
