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
Well, in the spirit of PHP, let's make version_compare_fixed()!
From the comments in the documentation, it seems others are having the same
problem withversion_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
Hi!
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".
1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.
it is hart to imagine a 1.0 followed by 1.0.0 in real world, but
the only reason for something like this that i can come up with
is that, for whatever reason, a project wants to change from
two component version numbers to three component ones right after
having done a 1.0. And in that case a 1.0.0 following the 1.0
would be a new release, even if it only differs by the extra .0
And so 1.0 < 1.0.0 would be perfectly correct.
--
hartmut
1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.it is hart to imagine a 1.0 followed by 1.0.0 in real world, but
the only reason for something like this that i can come up with
is that, for whatever reason, a project wants to change from
two component version numbers to three component ones right after
having done a 1.0. And in that case a 1.0.0 following the 1.0
would be a new release, even if it only differs by the extra .0And so 1.0 < 1.0.0 would be perfectly correct.
--
hartmut
I've had to use two digit version numbers when upgrading frameworks during
the 5.4 development phrase. This meant that version_compare('5.4', PHP_VERSION);
would return -1 for things like 5.4.0-beta1. Padding the 5.4 to 5.4.0 would've
broken the comparison, as well as changing the return value of
version_compare('5.4', PHP_VERSION); when running 5.4.0.
Simon Welsh
Admin of http://simon.geek.nz/
1.0.0 and 1.0 are different things.
I think the problem is, version numbers are different things to different
people - I guess the documentation maybe isn't clear enough on precisely
what version numbering scheme it's using. To most people, "1" and "1.0" are
the same thing, because they look like decimal-numbers to Americans. The
documentation doesn't state how leading zeroes or missing numbers are
treated in comparisons.
I just submitted a comment with a small script that runs version_compare()
on a list of version numbers -
1 lt 1.0
1.0 eq 1.00
1.00 lt 1.01
1.01 eq 1.1
1.1 lt 1.10
1.10 gt 1.10b
1.10b lt 1.10.0
I was a bit surprised at some of these, but they make sense now that I can
see how the version-number interpretation works...
On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
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".1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
1.01 eq 1.1
Could you explain this one to me? In every versioning system I've ever
used, 1.1 would be greater than 1.01, not equal.
On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Hi!
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".1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Yeah, that would definitely be a bug.
1.01 eq 1.1Could you explain this one to me? In every versioning system I've ever
used, 1.1 would be greater than 1.01, not equal.On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Hi!
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".1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
1.01 eq 1.1
Could you explain this one to me? In every versioning system I've ever
used, 1.1 would be greater than 1.01, not equal.
Because 01 is just a padded version of 1, probably used to make it easier for regular string comparisons (until you reach major version 10).
On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Hi!
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".1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
If you think 1.1 =/= 1.01 you're sure using some weird version numbers.
Only 1.0.1 would be smaller.
Has anyone seen these weird version ordering schemes in practise? On any
major projects of note?
1.01 eq 1.1
Could you explain this one to me? In every versioning system I've ever
used, 1.1 would be greater than 1.01, not equal.Because 01 is just a padded version of 1, probably used to make it easier
for regular string comparisons (until you reach major version 10).On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Hi!
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".1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Sat, Jul 21, 2012 at 3:09 AM, Andrew Faulds ajfweb@googlemail.comwrote:
If you think 1.1 =/= 1.01 you're sure using some weird version numbers.
Only 1.0.1 would be smaller.Has anyone seen these weird version ordering schemes in practise? On any
major projects of note?
raises his hand
1.01 and 1.0.1 are essentially the same thing. If a versioning model
doesn't utilize the second dot (many don't), then 1.01 would be the same as
1.0.1 in a project that does use it.
The Gitflow model reserves that last digit for hotfixes. However, many
developers (including myself) drop the second dot as it's pretty much
superfluous. Maybe that's an American thing, I dunno. But having 1.1 ==
1.01 would cause this function to be completely and utterly *worthless *for
many developers like myself.
--Kris
Kris Craig wrote:
raises his hand
1.01 and 1.0.1 are essentially the same thing. If a versioning model
doesn't utilize the second dot (many don't), then 1.01 would be the same as
1.0.1 in a project that does use it.The Gitflow model reserves that last digit for hotfixes. However, many
developers (including myself) drop the second dot as it's pretty much
superfluous. Maybe that's an American thing, I dunno. But having 1.1 ==
1.01 would cause this function to be completely and utterly *worthless *for
many developers like myself.
Sorry Kris, but the version number system that PHP uses by definition is three
numbers. We are currently on 5.4.x and the function is defined as
"version_compare() compares two "PHP-standardized" version number strings"
so as far as I am concerned most of this discussion has been irrelevant.
The comment posted to the page is equally in error as only one of the strings
are in what I would call "PHP-standardized". But the main point here is that the
function is DESIGNED to allow us to enable and disabled PHP actions based on the
version number of PHP, so as long as the version numbers are correctly set IN
PHP then there is nothing wrong with the function? Redefining a function to do a
job it is not defined for is simply wrong and if you want a function that works
for a different versioning system, then it's a new function!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Sat, Jul 21, 2012 at 3:09 AM, Andrew Faulds ajfweb@googlemail.comwrote:
If you think 1.1 =/= 1.01 you're sure using some weird version numbers.
Only 1.0.1 would be smaller.Has anyone seen these weird version ordering schemes in practise? On any
major projects of note?raises his hand
1.01 and 1.0.1 are essentially the same thing.
No, it is not.
If a versioning model doesn't utilize the second dot (many don't), then 1.01 would be the same as
1.0.1 in a project that does use it.
It's the first time I hear about a project writing 1.0.1 as 1.01
The Gitflow model reserves that last digit for hotfixes. However, many
developers (including myself) drop the second dot as it's pretty much
superfluous. Maybe that's an American thing, I dunno. But having 1.1 ==
1.01 would cause this function to be completely and utterly *worthless *for
many developers like myself.
It doesn't matter that you bump the minor or revision number, it's up to
each
project what should increase on a change of X severity. It would still
work flawlesslly
as far as you do it consistently.
If you release 1.0.1, 1.02, 1.0.3 and expect it to order that way, it
will fail. And I guess
that so would many developers too.
using this particular version-numbering scheme, 1.01 is equal to 1.1 - I
don't think that's a bug, because the version-numbers in this
version-numbering scheme are integers, not decimals.
so I believe this is in fact as correct as it can be, since numbers like
"01" should not really be used in this version-numbering scheme, as it's
not an integer.
changing it is probably not a good idea, since comparisons like "1.10" and
"1.100" could potentially become really tricky - in the current
version-numbering scheme, 100 is greater than 10, but if these were
interpreted as decimals, they would be equal.
looks like I opened up pandora's box with this one ;-)
bottom line, I think, is that version_compare() should work for the
version-numbering scheme used by PHP, so that it works for checking the PHP
version-number. if you happen to use the same version-numbering scheme for
your PHP projects, good for you - if you don't, too bad... there are just
too many version-numbering schemes to support them all...
1.01 eq 1.1Could you explain this one to me? In every versioning system I've ever
used, 1.1 would be greater than 1.01, not equal.On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Hi!
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".1.0.0 and 1.0 are different things. If you want to make a comparison
that takes into account only two components, you can just cut them both
to two components, then compare.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi!
Of course that would break backwards compatibility, which kind of defeats
the purpose of having a standardized version-number comparison standard.
x.y.z is standard, x.y not. I keep asking package maintainers to use
x.y.z as version and not x.y.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
What? x, x.y, x.y.z, x.y.z.a, etc are all valid.
1, 1.1, 1.1.2, 1.1.2.3, in that order, would be valid.
hi!
On Fri, Jul 20, 2012 at 2:40 PM, Rasmus Schultz rasmus@mindplay.dk
wrote:Of course that would break backwards compatibility, which kind of defeats
the purpose of having a standardized version-number comparison standard.x.y.z is standard, x.y not. I keep asking package maintainers to use
x.y.z as version and not x.y.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
No, I mean version with 1.0 and not 1.0.0 are not. They are just not
correct and confusing, as you noticed.
What? x, x.y, x.y.z, x.y.z.a, etc are all valid.
1, 1.1, 1.1.2, 1.1.2.3, in that order, would be valid.hi!
On Fri, Jul 20, 2012 at 2:40 PM, Rasmus Schultz rasmus@mindplay.dk
wrote:Of course that would break backwards compatibility, which kind of
defeats
the purpose of having a standardized version-number comparison standard.x.y.z is standard, x.y not. I keep asking package maintainers to use
x.y.z as version and not x.y.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
1, 1.0, 1.0.0, 1.0.0.0, 1.0.0.0.0 etc. are not confusing, they are
completely correct, and all mean the same thing.
If I publish MyApp v1, v1.0 and v1.0.0 are the same.
hi,
No, I mean version with 1.0 and not 1.0.0 are not. They are just not
correct and confusing, as you noticed.On Sat, Jul 21, 2012 at 11:19 AM, Andrew Faulds ajfweb@googlemail.com
wrote:What? x, x.y, x.y.z, x.y.z.a, etc are all valid.
1, 1.1, 1.1.2, 1.1.2.3, in that order, would be valid.hi!
On Fri, Jul 20, 2012 at 2:40 PM, Rasmus Schultz rasmus@mindplay.dk
wrote:Of course that would break backwards compatibility, which kind of
defeats
the purpose of having a standardized version-number comparison
standard.x.y.z is standard, x.y not. I keep asking package maintainers to use
x.y.z as version and not x.y.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
To follow that up, this is how version numbers are sorted:
1, 1.0, 1a, 1.0.1, 1.0.1a, 1.0.1.1, 2, 2.0.1
The first number is always most significant, followed by each number after
it (not necessarily single digits, ReactOS has 0.3.14 for instance), then
finally any letters at the end.
Equivalence is obvious: if a version (e.g. 3) is compared to one with more
numbers (e.g. 3.0.3), zeros are added until same: 3.0.0 vs 3.0.3. Now see
comparison rules.
hi,
No, I mean version with 1.0 and not 1.0.0 are not. They are just not
correct and confusing, as you noticed.On Sat, Jul 21, 2012 at 11:19 AM, Andrew Faulds ajfweb@googlemail.com
wrote:What? x, x.y, x.y.z, x.y.z.a, etc are all valid.
1, 1.1, 1.1.2, 1.1.2.3, in that order, would be valid.hi!
On Fri, Jul 20, 2012 at 2:40 PM, Rasmus Schultz rasmus@mindplay.dk
wrote:Of course that would break backwards compatibility, which kind of
defeats
the purpose of having a standardized version-number comparison
standard.x.y.z is standard, x.y not. I keep asking package maintainers to use
x.y.z as version and not x.y.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
No, I mean version with 1.0 and not 1.0.0 are not. They are just not
correct and confusing, as you noticed.
Then Linux 2.6.39 shouldn't have been followed by Linux 3.0
For me, 1.0 and 1.0.0 are the same thing.
It's fine if x.y is not a valid "PHP-standardized" version number,
and version_compare is thus undefined for it (despite lack of
definition of what forms a "PHP-standardized" version number).
But forcing third-parties to change their release numbers just to
please version_compare() is non-sense.
And if versoin_compare behavior is undefined for them, it can
(theoretically) be harmlessly changed.
Maybe it should have an optional extra parameter specifying comparison
"mode"? (I.e. version formatting)
hi,
No, I mean version with 1.0 and not 1.0.0 are not. They are just not
correct and confusing, as you noticed.
Then Linux 2.6.39 shouldn't have been followed by Linux 3.0For me, 1.0 and 1.0.0 are the same thing.
It's fine if x.y is not a valid "PHP-standardized" version number,
and version_compare is thus undefined for it (despite lack of
definition of what forms a "PHP-standardized" version number).
But forcing third-parties to change their release numbers just to
pleaseversion_compare()is non-sense.
And if versoin_compare behavior is undefined for them, it can
(theoretically) be harmlessly changed.