VersionNumber disallows zeros.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

VersionNumber disallows zeros.

Tobias Pape
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

Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

marcel.taeumel
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 <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

Jakob Reschke
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]>:
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 <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

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

Best,
Marcel

Am 21.09.2017 10:26:34 schrieb Jakob Reschke <[hidden email]>:

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]>:
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 <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

Bert Freudenberg
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:
If you cannot compare two versions, an error will be raised.

Best,
Marcel

Am 21.09.2017 10:26:34 schrieb Jakob Reschke <[hidden email]>:

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]>:
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 <[hidden email]>:

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







Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

marcel.taeumel
Here is a discussion about this topic from 2008:

It includes an explanation from Stephen Pair, who wrote the code:

Best,
Marcel

Am 21.09.2017 14:38:21 schrieb Bert Freudenberg <[hidden email]>:

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:
If you cannot compare two versions, an error will be raised.

Best,
Marcel

Am 21.09.2017 10:26:34 schrieb Jakob Reschke <[hidden email]>:

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]>:
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 <[hidden email]>:

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







Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

Bert Freudenberg
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 <[hidden email]> wrote:
Here is a discussion about this topic from 2008:

It includes an explanation from Stephen Pair, who wrote the code:

Best,
Marcel

Am 21.09.2017 14:38:21 schrieb Bert Freudenberg <[hidden email]>:

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:
If you cannot compare two versions, an error will be raised.

Best,
Marcel

Am 21.09.2017 10:26:34 schrieb Jakob Reschke <[hidden email]>:

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]>:
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 <[hidden email]>:

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











Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

Ian Trudel-2
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


Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

Ian Trudel-2
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]>:
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





Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

Nicolas Cellier
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 <[hidden email]>:
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]>:
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









Reply | Threaded
Open this post in threaded view
|

Re: VersionNumber disallows zeros.

Tobias Pape
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