VersionNumber disallows zeros.
Locked
 
|
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 |
Re: VersionNumber disallows zeros.
|
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
|
Re: VersionNumber disallows zeros.
|
|
In reply to this post by Tobias Pape
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" <[hidden email]>:
|
Re: VersionNumber disallows zeros.
|
|
If you cannot compare two versions, an error will be raised. Best, Marcel
|
Re: VersionNumber disallows zeros.
|
|
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 <[hidden email]> wrote:
|
Re: VersionNumber disallows zeros.
|
|
Here is a discussion about this topic from 2008: It includes an explanation from Stephen Pair, who wrote the code: Best, Marcel
|
Re: VersionNumber disallows zeros.
|
|
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 -
|
Re: VersionNumber disallows zeros.
|
|
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 |
Re: VersionNumber disallows zeros.
|
|
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 |
Re: VersionNumber disallows zeros.
|
|
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 <[hidden email]>:
|
Re: VersionNumber disallows zeros.
|
|
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). 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 forkBut 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 <[hidden email]>:
|
Re: VersionNumber disallows zeros.
|
|
In reply to this post by David T. Lewis
Hi
> On 22.09.2017, at 02:56, David T. Lewis <[hidden email]> 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.package/MetacelloSemanticVersionNumber.class and another based on Mozilla recommendations: https://github.com/Metacello/metacello/tree/master/repository/Metacello-Core.package/MetacelloVersionNumber.class They both have tests Best regards -Tobias |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |