Smalltalk › Squeak › Squeak - Dev

[squeak-dev] 1.0 not a valid VersionNumber?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Andreas.Raab

[squeak-dev] 1.0 not a valid VersionNumber?

Hi -

Just ran into the problem that

VersionNumber fromString: '1.0'.

complains that "VersionNumbers cannot contain zero or negative numbers".

Question: Is there an implementation dependency for that or is it simply
that VersionNumber is being overly paranoid here? In its current
incarnation it's basically useless for me and I'd rather have the check
be for negative numbers only.

Cheers,
- Andreas

John Thornborrow

Re: [squeak-dev] 1.0 not a valid VersionNumber?

Wouldn't that just be "Version 1" ?

Andreas Raab wrote:

> Hi -
>
> Just ran into the problem that
>
> VersionNumber fromString: '1.0'.
>
> complains that "VersionNumbers cannot contain zero or negative numbers".
>
> Question: Is there an implementation dependency for that or is it simply
> that VersionNumber is being overly paranoid here? In its current
> incarnation it's basically useless for me and I'd rather have the check
> be for negative numbers only.
>
> Cheers,
> - Andreas
>
>

--
John Thornborrow
http://www.pinesoft.co.uk

******************************************************************************************************************************************
This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. *******************************************************************************************************************************************

Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Andreas.Raab

[squeak-dev] Re: 1.0 not a valid VersionNumber?

John Thornborrow wrote:
> Wouldn't that just be "Version 1" ?

Simplified example. The real version number I'm interested in looks like
"1.0.34". But it looks like VersionNumber is a no-go for me anyway as
you can't even compare, e.g., '1.1.1' asVersion <= '1.2.3' asVersion.
Does anyone actually use VersionNumber? I must be missing the real use
cases for it.

Cheers,
- Andreas

>
> Andreas Raab wrote:
>> Hi -
>>
>> Just ran into the problem that
>>
>> VersionNumber fromString: '1.0'.
>>
>> complains that "VersionNumbers cannot contain zero or negative numbers".
>>
>> Question: Is there an implementation dependency for that or is it simply
>> that VersionNumber is being overly paranoid here? In its current
>> incarnation it's basically useless for me and I'd rather have the check
>> be for negative numbers only.
>>
>> Cheers,
>> - Andreas
>>
>>
>

Bert Freudenberg

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

On 09.04.2008, at 09:57, Andreas Raab wrote:
> John Thornborrow wrote:
>> Wouldn't that just be "Version 1" ?
>
> Simplified example. The real version number I'm interested in looks
> like "1.0.34". But it looks like VersionNumber is a no-go for me
> anyway as you can't even compare, e.g., '1.1.1' asVersion <= '1.2.3'
> asVersion. Does anyone actually use VersionNumber? I must be missing
> the real use cases for it.

Looks like SqueakMap is using it (see senders of #asVersion).

It's a bit odd in that something like this doesn't even work:

'1.1.1' asVersion < '1.2.1' asVersion

("different branches" error ...)

- Bert -

> Cheers,
> - Andreas
>
>> Andreas Raab wrote:
>>> Hi -
>>>
>>> Just ran into the problem that
>>>
>>> VersionNumber fromString: '1.0'.
>>>
>>> complains that "VersionNumbers cannot contain zero or negative
>>> numbers".
>>>
>>> Question: Is there an implementation dependency for that or is it
>>> simply
>>> that VersionNumber is being overly paranoid here? In its current
>>> incarnation it's basically useless for me and I'd rather have the
>>> check
>>> be for negative numbers only.
>>>
>>> Cheers,
>>> - Andreas
>>>
>>>
>
>

Stephen Pair

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

In reply to this post by Andreas.Raab

Wow, this is a blast from the past.

On Wed, Apr 9, 2008 at 12:57 PM, Andreas Raab <[hidden email]> wrote:

Question: Is there an implementation dependency for that or is it simply that VersionNumber is being overly paranoid here? In its current incarnation it's basically useless for me and I'd rather have the check be for negative numbers only.

That's just a design decision I made. I felt was would be confusing to have version numbers "1" and "1.0" in the same lineage. When you create a branch, you would make "1.1" based on "1".

John Thornborrow wrote:

Wouldn't that just be "Version 1" ?

Simplified example. The real version number I'm interested in looks like "1.0.34". But it looks like VersionNumber is a no-go for me anyway as you can't even compare, e.g., '1.1.1' asVersion <= '1.2.3' asVersion. Does anyone actually use VersionNumber? I must be missing the real use cases for it.

I'm curious whether you'd expect this to return true or false (I'm guess true). The reason it refuses that compasion is that #< is meant to test whether a given version number is an ancestor of another. If you want the stringish comparison behavior, you could just use string. Or, you could extend the class with a different comparison method to do what you want. The motivation for this class was to give a structured way to used dotted number strings to encapsulate information about versions and branches. I've copied the class comments below.

- Stephen

---------------------

I am a version number. My representation allows me to handle an entire tree of versions. Once created, an instance should not change (note: VersionNumbers could be canonicalized like Symbols, but are not currently).

I am a magnitude so that you can see if one version preceeds another (only if the two versions are in the same branch).

VersionNumber fromString: '1.0'.

'2.1' asVersion < '2.2.1' asVersion "true"

'2.3' asVersion < '2.2.1' asVersion "error different branches"

'2.3' asVersion inSameBranchAs: '2.2.1' asVersion "false, why the previous one failed."

'2.1' asVersion = '2.1' asVersion "true, obviously"

To get the next version number in the same branch:

'2.3.4' asVersion next "2.3.5"

To get the next version number, starting a new branch:

'2.3.4' asVersion branchNext "2.3.4.1"

To get the common base version of any two version numbers (useful for merging):

'2.3.8' asVersion commonBase: '2.3.4.1' asVersion "2.3.4"

Brett Kosinski

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

> That's just a design decision I made. I felt was would be confusing to have
> version numbers "1" and "1.0" in the same lineage. When you create a
> branch, you would make "1.1" based on "1".

Fundamentally, what this illustrates is that these version numbers are
imminently suitable for internal versioning of a product during
development, and are more or less akin to, say, SVN revision numbers
or the like (obviously with more semantics built in), but are wholly
unsuitable (and were probably never meant to be used) for
customer-facing version numbers that would be used for marking public
releases.

Brett.

Stephen Pair

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

On Wed, Apr 9, 2008 at 1:40 PM, Brett Kosinski <[hidden email]> wrote:

> That's just a design decision I made. I felt was would be confusing to have
> version numbers "1" and "1.0" in the same lineage. When you create a
> branch, you would make "1.1" based on "1".

Fundamentally, what this illustrates is that these version numbers are
imminently suitable for internal versioning of a product during
development, and are more or less akin to, say, SVN revision numbers
or the like (obviously with more semantics built in), but are wholly
unsuitable (and were probably never meant to be used) for
customer-facing version numbers that would be used for marking public
releases.

Brett.

Correct.

Stephen Pair

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

On Wed, Apr 9, 2008 at 1:41 PM, Stephen Pair <[hidden email]> wrote:

On Wed, Apr 9, 2008 at 1:40 PM, Brett Kosinski <[hidden email]> wrote:

> That's just a design decision I made. I felt was would be confusing to have
> version numbers "1" and "1.0" in the same lineage. When you create a
> branch, you would make "1.1" based on "1".

Fundamentally, what this illustrates is that these version numbers are
imminently suitable for internal versioning of a product during
development, and are more or less akin to, say, SVN revision numbers
or the like (obviously with more semantics built in), but are wholly
unsuitable (and were probably never meant to be used) for
customer-facing version numbers that would be used for marking public
releases.

Brett.

Correct.

I should have added, VersionHistory also let's you do a fair bit of reasoning and manipulation of and entire tree of VersionNumbers (including operations affecting an entire branch of version numbers).

- Stephen

Andreas.Raab

[squeak-dev] Re: 1.0 not a valid VersionNumber?

In reply to this post by Stephen Pair

Stephen Pair wrote:

> Simplified example. The real version number I'm interested in looks
> like "1.0.34". But it looks like VersionNumber is a no-go for me
> anyway as you can't even compare, e.g., '1.1.1' asVersion <= '1.2.3'
> asVersion. Does anyone actually use VersionNumber? I must be missing
> the real use cases for it.
>
>
> I'm curious whether you'd expect this to return true or false (I'm guess
> true). The reason it refuses that compasion is that #< is meant to test
> whether a given version number is an ancestor of another. If you want
> the stringish comparison behavior, you could just use string.

I wish...

'1.1.2' < '1.12.3'

=> false

Cheers,
- Andreas

Brett Kosinski

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

> Stephen Pair wrote:
>
> > Simplified example. The real version number I'm interested in looks
> > like "1.0.34". But it looks like VersionNumber is a no-go for me
> > anyway as you can't even compare, e.g., '1.1.1' asVersion <= '1.2.3'
> > asVersion. Does anyone actually use VersionNumber? I must be missing
> > the real use cases for it.
> >
> >
> > I'm curious whether you'd expect this to return true or false (I'm guess
> true). The reason it refuses that compasion is that #< is meant to test
> whether a given version number is an ancestor of another. If you want the
> stringish comparison behavior, you could just use string.
> >
>
> I wish...
>
> '1.1.2' < '1.12.3'
>
> => false

Yeah, fundamentally, what you're asking just doesn't make sense for
the semantics of the VersionNumber class. You're basically comparing
two revisions on different branches,.

It sounds to me like you need a separate ReleaseNumber class, or
something similar, that uses major.minor.patchlevel. Internally,
though, you should just be incrementing the VersionNumber
sequentially... then mapping the VersionNumber to some ReleaseNumber
when a release gets cut.

Brett.

Bert Freudenberg

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

On 09.04.2008, at 10:54, Brett Kosinski wrote:

>> Stephen Pair wrote:
>>
>>> Simplified example. The real version number I'm interested in
>>> looks
>>> like "1.0.34". But it looks like VersionNumber is a no-go for me
>>> anyway as you can't even compare, e.g., '1.1.1' asVersion <=
>>> '1.2.3'
>>> asVersion. Does anyone actually use VersionNumber? I must be
>>> missing
>>> the real use cases for it.
>>>
>>>
>>> I'm curious whether you'd expect this to return true or false (I'm
>>> guess
>> true). The reason it refuses that compasion is that #< is meant to
>> test
>> whether a given version number is an ancestor of another. If you
>> want the
>> stringish comparison behavior, you could just use string.
>>>
>>
>> I wish...
>>
>> '1.1.2' < '1.12.3'
>>
>> => false
>
> Yeah, fundamentally, what you're asking just doesn't make sense for
> the semantics of the VersionNumber class. You're basically comparing
> two revisions on different branches,.
>
> It sounds to me like you need a separate ReleaseNumber class, or
> something similar, that uses major.minor.patchlevel. Internally,
> though, you should just be incrementing the VersionNumber
> sequentially... then mapping the VersionNumber to some ReleaseNumber
> when a release gets cut.

I like a "natural ordering" approach to this: split the string into
runs of letters, digits, and others. Then compare numerically for all-
digit runs and alphabetically for the rest:

SequenceableCollection>>sortsBefore: anotherCollection
1 to: self size do: [:i |
(self at: i) < (anotherCollection at: i) ifTrue: [^true].
(anotherCollection at: i) < (self at: i) ifTrue: [^false]].
^self size < anotherCollection size

String>>findSortTokens
| in p |
^Array streamContents: [:tokens |
in := self readStream.
p := in position.
[in atEnd] whileFalse: [
[in atEnd not and: [in peek isLetter]] whileTrue: [in next].
in position > p ifTrue:
[tokens nextPut: (self copyFrom: p+1 to: (p := in position))].
[in atEnd not and: [in peek isDigit]] whileTrue: [in next].
in position > p ifTrue:
[tokens nextPut: (self copyFrom: p+1 to: (p := in position))
asNumber].
[in atEnd not and: [in peek isAlphaNumeric not]] whileTrue: [in
next].
in position > p ifTrue:
[tokens nextPut: (self copyFrom: p+1 to: (p := in position))]]]

'1.1alpha' findSortTokens sortsBefore: '1.10beta' findSortTokens => true

(I also like this order for file lists in general - the Mac Finder
uses something similar)

- Bert -

Stephen Pair

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

In reply to this post by Andreas.Raab

On Wed, Apr 9, 2008 at 1:49 PM, Andreas Raab <[hidden email]> wrote:

Stephen Pair wrote:

Simplified example. The real version number I'm interested in looks
like "1.0.34". But it looks like VersionNumber is a no-go for me
anyway as you can't even compare, e.g., '1.1.1' asVersion <= '1.2.3'
asVersion. Does anyone actually use VersionNumber? I must be missing
the real use cases for it.

I'm curious whether you'd expect this to return true or false (I'm guess true). The reason it refuses that compasion is that #< is meant to test whether a given version number is an ancestor of another. If you want the stringish comparison behavior, you could just use string.

I wish...

'1.1.2' < '1.12.3'

=> false

Did you actually mean true? (if not, I don't actually get what you're after)...VersionNumber aside, I wonder what you could reasonably infer from answer answer of true given for '1.1.2' < '1.12.3' ...I don't think you could infer that 1.12.3 was published after 1.1.2 for example. I don't think you could infer that 1.12.3 includes everything in included in 1.1.2 (i.e. that 1.12.3 is derived from 1.1.2). About all you could infer is that 1 < 12.

- Stephen

Andreas.Raab

[squeak-dev] Re: 1.0 not a valid VersionNumber?

Stephen Pair wrote:
> Did you actually mean true? (if not, I don't actually get what you're
> after)...VersionNumber aside, I wonder what you could reasonably infer
> from answer answer of true given for '1.1.2' < '1.12.3' ...I don't think
> you could infer that 1.12.3 was published after 1.1.2 for example. I
> don't think you could infer that 1.12.3 includes everything in included
> in 1.1.2 (i.e. that 1.12.3 is derived from 1.1.2). About all you could
> infer is that 1 < 12.

Which is precisely what I was after.

Cheers,
- Andreas

Tapple Gao

Re: [squeak-dev] Re: 1.0 not a valid VersionNumber?

On Wed, Apr 09, 2008 at 01:35:21PM -0700, Andreas Raab wrote:

> Stephen Pair wrote:
>> Did you actually mean true? (if not, I don't actually get what you're
>> after)...VersionNumber aside, I wonder what you could reasonably infer
>> from answer answer of true given for '1.1.2' < '1.12.3' ...I don't think
>> you could infer that 1.12.3 was published after 1.1.2 for example. I
>> don't think you could infer that 1.12.3 includes everything in included in
>> 1.1.2 (i.e. that 1.12.3 is derived from 1.1.2). About all you could infer
>> is that 1 < 12.
>
> Which is precisely what I was after.

Keith Hodges Kernel extensions has a method that does just that.
http://www.squeaksource.com/311

SequencableCollection>>#<= otherCollection

"comparison for multi key sorts. note how boolean and nil IS supported for sorting"

| a b |
1 to: (self size min: otherCollection size) do: [ :index |
a := self at: index. b := otherCollection at: index.

(a == true and: [ b == false ]) ifTrue: [ ^ false ].
(a == false and: [ b == true ]) ifTrue: [ ^ true ].

a isNil ifTrue: [ ^ true ].
b isNil ifTrue: [ ^ false ].

a ~= b ifTrue: [ ^ a <= b ].

].

^ self size <= otherCollection size

"
#(1 2) <= #(1 3)
#(1 2 3) <= #(1 2)
#(1 2 3) <= #(1 3)
#(1 3) <= #(1 1)
#(1 2 false) <= #(1 2 true)
#(1 2 true) <= #(1 2 false)
#(1 2 true) <= #(1 2 nil)
"

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

SequenceableCollection-<=.st (852 bytes) Download Attachment