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
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 [mailto: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 [mailto: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
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
Here is a discussion about this topic from 2008: http://forum.world.st/squeak-dev-1-0-not-a-valid-VersionNumber-td74872.html [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... [http://forum.world.st/squeak-dev-1-0-not-a-valid-VersionNumber-tp74872p74875...]
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 [mailto: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 [mailto: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 [mailto: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 [mailto: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
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
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
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
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
Hi
On 22.09.2017, at 02:56, David T. Lewis lewis@mail.msen.com wrote:
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.
There's actually a pretty good (semantic) Version number implementation in Metacello (done by Dale in 2012):
https://github.com/Metacello/metacello/tree/master/repository/Metacello-Core...
and another based on Mozilla recommendations:
https://github.com/Metacello/metacello/tree/master/repository/Metacello-Core...
They both have tests
Best regards -Tobias
squeak-dev@lists.squeakfoundation.org