What is the current behavior if two branched version numbers are compared? true, false, error?

I would say they are not comparable anyway. What do you want to know? "Can I upgrade to get an increment?" "Can I upgrade without breaking some API?" "Which is newer?" All of these cannot be answered without additional information about the versioning scheme (e.g., in SemVer you could answer the first two queries, but not the third without an additional timestamp). And these queries should have their own messages instead of a general-purpose comparison.

Kind regards,

Jakob

Am 21.09.2017 08:44 schrieb "Taeumel, Marcel" <Marcel.Taeumel@hpi.de>:

Hi Tobias,

I see several issues with the current implementation of VersionNumber. :)

- You cannot compare 4.1 to 3.1 because such branches are treated unordered.

- You cannot even compare 4.1.1 to 4.2.1 for the same reason. But you can compare 4.1 to 4.2 though.

This logic might be the reason to throw out the zero all together: 4.1 and 4.1.0 are not so different, yet the first will be comparable but the second will not. That "branch logic" seems to be the key. Try changing #initializeNumbers: to accept zero and then play around with the comparison logic.

It's kind of weird or at least incomprehensible. I cannot find useful comments either.

Best,

Marcel

Am 20.09.2017 20:34:36 schrieb Tobias Pape <das.linux@gmx.de>:
Hi,

what's the rationale of VersionNumber prohibiting zeros in any of the version parts?
Eg, 4.0.3 is not a valid VersionNumber currently.

Best regards
-Tobias