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

Reply via email to