Follow-up Comment #7, bug #20680 (project freeciv):
> Problem is in documentation. I had hard time deciding which
> order cvercmp -binary should take parameters as neither seemed
> to work as "natural" in all contexts.
Sorry, I was unclear -- I think the algorithm is giving the wrong answer.
I.e., it's such that Freeciv will consider "2.4.0" older than "2.4.0-beta1"
when the time comes.
(As it happens, I think the old, pre-r19 order of the command-line arguments
is more intuitive.)
This is probably getting off-topic for this ticket, but with the old (pre-r19)
command-line argument order ("X greater Y" means "is X greater than Y"):
2.3.4 greater 2.4.0 No # good
2.3.4 greater 2.4.0-beta1 No # good
2.4.0-beta1 greater 2.3.4 Yes # good
2.4.0-beta2 greater 2.4.0-beta1 Yes # good
2.4.0-beta2 greater 2.4.0-beta2 No # good
2.4.0-beta1+ greater 2.4.0-beta1 Yes # good
2.4.0 greater 2.4.0-beta1 No # bad
2.4.0 greater 2.4.0-special No # good, probably
2.4.0 greater 2.4.0-beta Yes # good
I think the code around the comment /* Longer version number is greater if all
the parts up to end of shorter one are equal. */ needs to either subtokenize
(so that the cvercmp_parse_prever() spots "beta1" as a thing that reverses the
order), or cvercmp_parse_prever() needs to have a match-only-prefix mode.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?20680>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
[email protected]
https://mail.gna.org/listinfo/freeciv-dev
