# common issue with version_compare() - Thread: https://externals.io/message/61561 - Original archive: https://news-web.php.net/php.internals/61561 - Started by Rasmus Schultz on 2012-07-20T12:40:36+00:00 - Messages: 21 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #61561 — Rasmus Schultz — 2012-07-20T12:40:36+00:00 URL: https://externals.io/message/61561#61561 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 --- ## #61580 — Andrew Faulds — 2012-07-20T20:57:32+00:00 URL: https://externals.io/message/61561#61580 · In reply to: #61561 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 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 --- ## #61581 — Stas Malyshev — 2012-07-20T21:07:54+00:00 URL: https://externals.io/message/61561#61581 · In reply to: #61580 Hi! > > […] 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 --- ## #61583 — Hartmut Holzgraefe — 2012-07-20T22:22:30+00:00 URL: https://externals.io/message/61561#61583 · In reply to: #61581 > 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 --- ## #61588 — Simon J Welsh — 2012-07-20T22:38:08+00:00 URL: https://externals.io/message/61561#61588 · In reply to: #61583 > > > […] > > 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 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/ --- ## #61598 — Rasmus Schultz — 2012-07-21T03:19:40+00:00 URL: https://externals.io/message/61561#61598 · In reply to: #61581 > 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 wrote: > Hi! > > > […] > shortest > > […] > would be > > […] > > 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 --- ## #61600 — Kris Craig — 2012-07-21T06:22:33+00:00 URL: https://externals.io/message/61561#61600 · In reply to: #61598 > 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 wrote: > > > […] --- ## #61602 — Andrew Faulds — 2012-07-21T07:52:23+00:00 URL: https://externals.io/message/61561#61602 · In reply to: #61600 Yeah, that would definitely be a bug. > > […] > > 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. > > > […] --- ## #61608 — Pierre Joye — 2012-07-21T09:06:41+00:00 URL: https://externals.io/message/61561#61608 · In reply to: #61561 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 --- ## #61609 — Andrew Faulds — 2012-07-21T09:19:05+00:00 URL: https://externals.io/message/61561#61609 · In reply to: #61608 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 > wrote: > > > […] > > 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 --- ## #61610 — Pierre Joye — 2012-07-21T09:32:33+00:00 URL: https://externals.io/message/61561#61610 · In reply to: #61609 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. > > > > […] > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #61611 — Andrew Faulds — 2012-07-21T09:37:53+00:00 URL: https://externals.io/message/61561#61611 · In reply to: #61610 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 > wrote: > > […] > standard. > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #61613 — Andrew Faulds — 2012-07-21T09:45:28+00:00 URL: https://externals.io/message/61561#61613 · In reply to: #61610 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 > wrote: > > […] > standard. > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #61612 — Tjerk Meesters — 2012-07-21T09:46:05+00:00 URL: https://externals.io/message/61561#61612 · In reply to: #61600 > > […] > > 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). > > > […] --- ## #61614 — Andrew Faulds — 2012-07-21T10:09:07+00:00 URL: https://externals.io/message/61561#61614 · In reply to: #61612 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? > > > > > > […] > > 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). > > > […] --- ## #61617 — keisial@gmail.com — 2012-07-21T12:07:38+00:00 URL: https://externals.io/message/61561#61617 · In reply to: #61610 > 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. --- ## #61618 — Andrew Faulds — 2012-07-21T12:11:16+00:00 URL: https://externals.io/message/61561#61618 · In reply to: #61617 Maybe it should have an optional extra parameter specifying comparison "mode"? (I.e. version formatting) > > > […] > 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. --- ## #61623 — Rasmus Schultz — 2012-07-22T01:52:41+00:00 URL: https://externals.io/message/61561#61623 · In reply to: #61600 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... > > > […] > > 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. > > > […] --- ## #61624 — Kris Craig — 2012-07-22T02:08:50+00:00 URL: https://externals.io/message/61561#61624 · In reply to: #61614 On Sat, Jul 21, 2012 at 3:09 AM, Andrew Faulds wrote: > 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 --- ## #61626 — Lester Caine — 2012-07-22T07:01:00+00:00 URL: https://externals.io/message/61561#61626 · In reply to: #61624 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 --- ## #61648 — keisial@gmail.com — 2012-07-23T15:29:35+00:00 URL: https://externals.io/message/61561#61648 · In reply to: #61624 > On Sat, Jul 21, 2012 at 3:09 AM, Andrew Faulds wrote: > > > […] > *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.