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
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to