That sounds nonsensical. 4.1 should be larger than 3.1, and smaller than 4.1.0. Direct comparison is strictly for listing versions in ascending order, and as Jakob wrote, you need a more complex scheme for other purposes.

- Bert -

On Thu, Sep 21, 2017 at 10:47 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

If you cannot compare two versions, an error will be raised.

Best, Marcel

Am 21.09.2017 10:26:34 schrieb Jakob Reschke <jakob.reschke@student.hpi.de

...

:

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

I dimly remember that. Didn't make sense then, doesn't now. Can we just fix it? Existing code that avoids comparing these versions, or doesn't use ".0" should not break.

- Bert -

On Thu, Sep 21, 2017 at 2:57 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Here is a discussion about this topic from 2008: http://forum.world.st/squeak-dev-1-0-not-a-valid- VersionNumber-td74872.html

It includes an explanation from Stephen Pair, who wrote the code: http://forum.world.st/squeak-dev-1-0-not-a-valid- VersionNumber-tp74872p74875.html

Best, Marcel

Am 21.09.2017 14:38:21 schrieb Bert Freudenberg bert@freudenbergs.de: That sounds nonsensical. 4.1 should be larger than 3.1, and smaller than 4.1.0. Direct comparison is strictly for listing versions in ascending order, and as Jakob wrote, you need a more complex scheme for other purposes.

• Bert -

On Thu, Sep 21, 2017 at 10:47 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

...

If you cannot compare two versions, an error will be raised.

Best, Marcel

Am 21.09.2017 10:26:34 schrieb Jakob Reschke < jakob.reschke@student.hpi.de>: 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

On Thu, Sep 21, 2017 at 01:53:45PM -0400, Ian Trudel wrote:

VersionNumber was particular from the ground up. It was not documented until I wrote VersionNumberTest back in 2009.

The fact that it was not supporting 0 was odd but the tests were written to conform to what was already there.

The idea was if someone wants to change VersionNumber, they could change VersionNumberTest first and ensure an easy transition while retaining (some or full) compatibility.

Ian,

Thank you for this. Writing VersionNumberTest was exactly the right thing to do in this case, and the current discussion shows why it was important for you to do it.

I was just about to respond to this thread with something along the lines of "change it any way you want, but please be sure to document it with unit tests".

And of course you also provided a meaningful class comment in VersionNumberTest that provides some background for this discossion, so thanks also for that.

:-)

Dave

I didn't read any code nor test (bad), but I'm trying to reinvent the logic from this thread without being too much tainted (good).

Let's say i have a trunk with 5 versions:

1---2---3---4---5

If I want to fork from version 2, I'll create a 2.1:

1---2---3---4---5 --2.1--2.2--2.3

Hence 2.2 and for example 4.1 are not so well ordered, both branches have specific changes

So if I understand VersionNumber, adding a .1 means 2 things: - creating a fork - pushing some changes

But what if I want to create a second fork from 2??? We could have distinguished forking without doing any change (create a 2.0) then push changes

1---2---3---4---5 | 2.0--2.1--2.2--2.3

In which case, we can create a 2.0.0 if we want another fork. That's not so nice, we have to fork from latest fork and not from trunk... But that can eventually work if VersionNumber is omniscient:

1---2---3---4---5 | 2.0--2.1--2.2--2.3 | 2.0.0---2.0.1--2.0.2--2.0.3

So, IMO zero makes sense and SHOULD mean fork (then 2=2.0 and 2=2.0.0 in the sense that they have same code). Otherwise how mulitple forks work in VersionNumber without a zero?

Or does 2.1 just means fork without any change? In which case, 2=2.1 and 2=2.1.1 which sounds weird (why zero was invented for then?).

2017-09-22 7:28 GMT+02:00 Ian Trudel ian.trudel@gmail.com:

Thanks Dave! VersionNumberTest is very modest but your message made my day. There were no compelling reason to write the test in 2009 but just to say every contribution comes to be helpful at some point. We got to love Open Source. :)

Ian

2017-09-21 20:56 GMT-04:00 David T. Lewis lewis@mail.msen.com:

...

On Thu, Sep 21, 2017 at 01:53:45PM -0400, Ian Trudel wrote:

...

VersionNumber was particular from the ground up. It was not documented until I wrote VersionNumberTest back in 2009.

The fact that it was not supporting 0 was odd but the tests were

written to

...

conform to what was already there.

The idea was if someone wants to change VersionNumber, they could change VersionNumberTest first and ensure an easy transition while retaining

(some

...

or full) compatibility.

Ian,

Thank you for this. Writing VersionNumberTest was exactly the right thing to do in this case, and the current discussion shows why it was important for you to do it.

I was just about to respond to this thread with something along the lines of "change it any way you want, but please be sure to document it with unit tests".

And of course you also provided a meaningful class comment in VersionNumberTest that provides some background for this discossion, so thanks also for that.

:-)

Dave