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. On Jul 21, 2012 10:32 AM, "Pierre Joye" <pierre....@gmail.com> wrote: > 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 <ajf...@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. > > > > On Jul 21, 2012 10:07 AM, "Pierre Joye" <pierre....@gmail.com> wrote: > >> > >> hi! > >> > >> On Fri, Jul 20, 2012 at 2:40 PM, Rasmus Schultz <ras...@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 > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > > > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >
