Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61561
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.220.170 cause and error)
MIME-Version: 1.0
Date: Fri, 20 Jul 2012 08:40:36 -0400
Message-ID: <CADqTB_jrj__c-1d=F2zuK_Rj4J_HpXkrqPgA3J57Nxi7WBTBTg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307f34baeb101004c542334b
Subject: common issue with version_compare()
From: rasmus@mindplay.dk (Rasmus Schultz)

--20cf307f34baeb101004c542334b
Content-Type: text/plain; charset=ISO-8859-1

From the comments in the documentation, it seems others are having the same
problem with version_compare() that I was running into:

http://us2.php.net/version_compare

Look at all those code-samples and "extensions" to the function - I found
it very odd that the documentation does not explain how an "empty"
version-number is interpreted compared to the strings and numbers, which
are clearly defined and explained.

For example, I was not the only one who found it odd that "1.0" is
considered less than "1.0.0" - wouldn't it make sense to "pad" the shortest
version-number with zeroes? e.g. "1.0" if compared against "1.0.0" would be
padded with zeroes at the end, e.g. as "1.0.0".

Of course that would break backwards compatibility, which kind of defeats
the purpose of having a standardized version-number comparison standard.
But as you can see, people aren't using the function as-is anyway - they're
writing their own...

- Rasmus Schultz

--20cf307f34baeb101004c542334b--