Collation of release numbers

Jim DeLaHunt from.gnucash at jdlh.com
Thu Jan 25 14:10:22 EST 2018


Gnucash developers:

I am reading the thread about release numbering schemes with interest. I 
don't have strong opinions on the big issues you are discussing. I would 
like to touch on a small issue which hasn't come up yet:

*Collation of release numbers*

When you define the new release numbering scheme, be sure to be clear 
about how to determine if one release number is newer or older than 
another release number.  In particular, there's a temptation to do 
lexical comparisons of release numbers, but numeric comparisons by 
number part is probably better.

It's no problem to determine that version 3.1.0 is newer than version 
3.0.9, and that 3.1.2 is newer than 3.1.0.

But, is 3.0.10 newer than 3.0.9?  If comparing lexically, then no. If 
treating the version number as a sequence of three parts, and comparing 
each part numerically, then yes.

There was talk about using version number parts in the 80's or 90's for 
development releases leading up to a new production release.  For 
instance, 3.1.2 and 3.1.9 and 3.1.10 would be production releases in the 
3.1 line; 3.1.80 and 3.1.81 would be development releases leading up to 
3.2.0 and the 3.2 line.  With lexical ordering, 3.1.80 sorts before 
3.1.9, which is wrong. (3.1.10 sorts lexically before 3.1.9, which is 
also wrong.)  If using numbers in the 80's and 90's for development 
releases, it's especially important to be clear that version numbers are 
compared numerically by number part.

Also, be clear if anything but an unsigned integer value is permitted in 
a version.  Will there ever be a version number format like "3.0.1b2"?

Also, be clear if leading zeros are permitted in a version number. Is 
"3.1.09" permitted?   Is it another way to express "3.1.9", or does it 
mean something different?

No matter what version numbering scheme you adopt next, and no matter 
how the semantics of the version number tie to the development process, 
I think it will be helpful to be explicit and clear about collation of 
version numbers.

Thank you,
       —Jim DeLaHunt, Vancouver, Canada

-- 
     --Jim DeLaHunt, jdlh at jdlh.com     http://blog.jdlh.com/ (http://jdlh.com/)
       multilingual websites consultant

       355-1027 Davie St, Vancouver BC V6E 4L2, Canada
          Canada mobile +1-604-376-8953



More information about the gnucash-devel mailing list