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