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 at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170921/3e00ed16/attachment.html>