Metacello version format

After a conversation with Julian Fitzell on the  Seaside Dev list[1],
I realized two things:

  1. I hadn't really publicized the version format that I use with
Metacello
  2. the version format that is used by Metacello could probably be
better

To address the first point, I've create Version format page[2] on the
wiki to document the current version format. For comparison, I
encourage you to look at the version format used by Mozilla[3].

I cloned the Metacello version page from Mozilla version page, so it
should be easy to compare descriptions.

Here are some examples from the Mozilla page:

1.-1
< 1 == 1. == 1.0 == 1.0.0
< 1.1a < 1.1aa < 1.1ab < 1.1b < 1.1c
< 1.1pre == 1.1pre0 == 1.0+
< 1.1pre1a < 1.1pre1aa < 1.1pre1b < 1.1pre1
< 1.1pre2
< 1.1pre10
< 1.1.-1
< 1.1 == 1.1.0 == 1.1.00
< 1.10
< 1.* < 1.*.1
< 2.0

And here are the same examples converted to Metacello:

1 == 1. < 1.0 == 1..--0
< 1.1-a < 1.1-aa < 1.1-ab < 1.1-b < 1.1-c
< 1.1-pre < 1.1-pre.0
< 1.1-pre.1-a < 1.1-pre.1-aa < 1.1-pre.1-b < 1.1-pre.1
< 1.1-pre.2
< 1.1-pre.10
< 1.1 < 1.1.0 < 1.1.00
< 1.10
< 2.0

After the conversation with Julian, after looking at the Mozilla
format, and after scanning through the already created Configurations,
I think that it is possible to support a combination of Mozilla and
Metacello formats, where at least there can be a set of rules for
comparing. In the proposed version format the following comparison
should illustrate what I am thinking:

1.1-pre == 1.1pre < 1.1-pre.0 == 1.1pre0

I assume that the Mozilla format is preferred over the Metacello
format, but the dashes would be there mainly for backward
compatibility.

During the conversation, Julian made the following comment:

  Seems like that's always going to depend on people following a
  particular convention. So either you force everyone to use the same
  convention for their projects (not likely) or accept that the
  Metacello version number may not match the project's own numbering
  character-by-character... no?

Of course he is correct. It should be noted that the only reason that
a version format is important is to provide a sort order. Within Pharo
a common format should be used, but individuals using Metacello for
their own nefarious purposes shouldn't have to follow the version
format convention.

So I plan on making it possible that the version sorting rules can be
controlled on a configuration by configuration basis.
MetacelloVersionNumber will have a fromString: method that will parse
a given version string using the Metacello version format.

However, if a configuration implements a particular method (to be
named later), the configuration will be asked to produce a
MetacelloVersionNumber from a given string. I assume that in the worst
case, the configuration can map a list of arbitrary version numbers to
an ordinal number for the MetacelloVersionNumber so that basically all
version formats (including totally arbitrary ones) can be
accommodated.

I would like to know if folks generally agree with the Mozilla version
format (I'm assuming unanimity is impossible) and suggest alternatives
if there are better ones ... I'm inclined to keep the dash convention
for backward compatibility, but I'm not strongly married to that idea
since there will be a way to handle arbitrary version strings, I'm not
real worried about backward compatibility.

Thoughts are welcome.

Dale

[1] - http://n4.nabble.com/Seaside-dev-beta-td1556607.html#a1556607
[2] - http://code.google.com/p/metacello/wiki/VersionFormat
[3] - https://developer.mozilla.org/en/Toolkit_version_format

On Feb 19, 2010, at 2:09 AM, Dale wrote:

it took me a while to understand the expression above. this is ok now I got it but
we should avoid 1..  looks ugly.
I like the idea to use - to separate number from the rest.
Your conventions is there is always a - before an letter

----- "stephane ducasse" <[hidden email]> wrote:

| On Feb 19, 2010, at 2:09 AM, Dale wrote:
|
| > After a conversation with Julian Fitzell on the  Seaside Dev
| list[1],
| > I realized two things:
| >
| >  1. I hadn't really publicized the version format that I use with
| > Metacello
| >  2. the version format that is used by Metacello could probably be
| > better
| >
| > To address the first point, I've create Version format page[2] on
| the
| > wiki to document the current version format. For comparison, I
| > encourage you to look at the version format used by Mozilla[3].
| >
| > I cloned the Metacello version page from Mozilla version page, so
| it
| > should be easy to compare descriptions.
| >
| > Here are some examples from the Mozilla page:
| >
| > 1.-1
| > < 1 == 1. == 1.0 == 1.0.0
| > < 1.1a < 1.1aa < 1.1ab < 1.1b < 1.1c
| > < 1.1pre == 1.1pre0 == 1.0+
| > < 1.1pre1a < 1.1pre1aa < 1.1pre1b < 1.1pre1
| > < 1.1pre2
| > < 1.1pre10
| > < 1.1.-1
| > < 1.1 == 1.1.0 == 1.1.00
| > < 1.10
| > < 1.* < 1.*.1
| > < 2.0
| >
| > And here are the same examples converted to Metacello:
| >
| > 1 == 1. < 1.0 == 1..--0
|
| it took me a while to understand the expression above. this is ok now
| I got it but
| we should avoid 1..  looks ugly.

No kidding. I thought I would be faithful to the actual algorithm rather than hide that wart:) I plan on adopting the Mozilla format where trailing 0 parts are not significant so the following will be true and empty parts will be invalid:

  1 == 1. == 1.0 == 1.0.0

Currently I don't throw errors when parsing a version number string ... if the version part separated by dots (no dashes) cannot be converted to an integer, I automatically convert it to a string (and the printString uses the leading dash). For the new implementation, I will throw errors, since there will be a back door for accepting any version format, I'm less worried about errors.

| I like the idea to use - to separate number from the rest.
| Your conventions is there is always a - before an letter

By using the dash it is possible to include any sequence of ASCII characters in a version string, if you are so inclined. I want to accept the Mozilla convention as well, because it is commonly used in email about versions of various projects. So the following version strings would be accepted:

  1.1-pre == 1.1pre < 1.1-pre.0 == 1.1pre0

Keeping the explicit dash allows us to do things like the following:

  1.1-00 < 1.1-00pre < 1.1pre < 1.1-pre-00 < 1.1pre0

| > [1] - http://n4.nabble.com/Seaside-dev-beta-td1556607.html#a1556607
| > [2] - http://code.google.com/p/metacello/wiki/VersionFormat
| > [3] - https://developer.mozilla.org/en/Toolkit_version_format

Dale

On Fri, Feb 19, 2010 at 11:25 AM, Dale Henrichs
<[hidden email]> wrote:
>  1.1-00 < 1.1-00pre < 1.1pre < 1.1-pre-00 < 1.1pre0

I'm not personally attached to Mozilla's format - it was merely an
example of a defined format that seems simple but also to allow most
things people need. But I don't think the above is correct by their
definition, unless I'm misunderstanding what you're doing with the
dashes (you are proposing them as an optional way of separating
sub-parts, so you can have two numeric parts in a row?)

"A string-part that exists is always less-then a nonexisting
string-part (1.6a  is less than 1.6)."

So it seems like 1.1-00pre < 1.1-00 (certainly intuitively one would
hope that was the case).

Also, since trailing zeros are not significant, I'm not sure why
1.1pre, 1.1-pre-00, and 1.1pre0 aren't equivalent.

Finally, Mozilla's format enforces that each version part be
<number><alpha><number><alpha> (each part being optional). This means
you can always compare any two versions. If you're doing what I think
you're doing with the dash, it seems like you could run into cases
where you are asked to compare, e.g. 1.1-12 and 1.1b, which means you
are forced to compare 12 to b.

Since all of these involve dashes, perhaps I'm just misunderstanding
what you're proposing.

Julian

Julian,

I _was_ emphasizing that the dashes would force interpretation of the  characters up to the next delimiter as strings. The Mozilla convention would be bypassed for those version parts preceded by a dash.

What makes the Mozilla format interesting is that it provides an interpretation for a version string like '1.0a6' or '1.0r43' that most likely matches the interpretation of the writer of such a string.

The current Metacello version format interprets the version strings as '1-0a6' and '1-0r43' which I'm pretty sure doesn't match expectations from a sorting perspective.

Dale

----- "Julian Fitzell" <[hidden email]> wrote:

| On Fri, Feb 19, 2010 at 11:25 AM, Dale Henrichs
| <[hidden email]> wrote:
| >  1.1-00 < 1.1-00pre < 1.1pre < 1.1-pre-00 < 1.1pre0
|
| I'm not personally attached to Mozilla's format - it was merely an
| example of a defined format that seems simple but also to allow most
| things people need. But I don't think the above is correct by their
| definition, unless I'm misunderstanding what you're doing with the
| dashes (you are proposing them as an optional way of separating
| sub-parts, so you can have two numeric parts in a row?)
|
| "A string-part that exists is always less-then a nonexisting
| string-part (1.6a  is less than 1.6)."
|
| So it seems like 1.1-00pre < 1.1-00 (certainly intuitively one would
| hope that was the case).
|
| Also, since trailing zeros are not significant, I'm not sure why
| 1.1pre, 1.1-pre-00, and 1.1pre0 aren't equivalent.
|
| Finally, Mozilla's format enforces that each version part be
| <number><alpha><number><alpha> (each part being optional). This means
| you can always compare any two versions. If you're doing what I think
| you're doing with the dash, it seems like you could run into cases
| where you are asked to compare, e.g. 1.1-12 and 1.1b, which means you
| are forced to compare 12 to b.
|
| Since all of these involve dashes, perhaps I'm just misunderstanding
| what you're proposing.
|
| Julian

El vie, 19-02-2010 a las 14:05 -0800, Dale Henrichs escribió:
> Julian,
>
> I _was_ emphasizing that the dashes would force interpretation of the  characters up to the next delimiter as strings. The Mozilla convention would be bypassed for those version parts preceded by a dash.
>
> What makes the Mozilla format interesting is that it provides an interpretation for a version string like '1.0a6' or '1.0r43' that most likely matches the interpretation of the writer of such a string.
>
> The current Metacello version format interprets the version strings as '1-0a6' and '1-0r43' which I'm pretty sure doesn't match expectations from a sorting perspective.
>

Aha! then that is the reason that when loading ConfigurationOfMagma I
get a progress bar with 1-0r43 instead of 1.0r43. Some weeks ago I
intended to ask but as the loading worked ok I thought that is was a
minor bug.
:)

Cheers
--
Miguel Cobá
http://miguel.leugim.com.mx

----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote:

| El vie, 19-02-2010 a las 14:05 -0800, Dale Henrichs escribió:
| > Julian,
| >
| > I _was_ emphasizing that the dashes would force interpretation of
| the  characters up to the next delimiter as strings. The Mozilla
| convention would be bypassed for those version parts preceded by a
| dash.
| >
| > What makes the Mozilla format interesting is that it provides an
| interpretation for a version string like '1.0a6' or '1.0r43' that most
| likely matches the interpretation of the writer of such a string.
| >
| > The current Metacello version format interprets the version strings
| as '1-0a6' and '1-0r43' which I'm pretty sure doesn't match
| expectations from a sorting perspective.
| >
|
| Aha! then that is the reason that when loading ConfigurationOfMagma I
| get a progress bar with 1-0r43 instead of 1.0r43. Some weeks ago I
| intended to ask but as the loading worked ok I thought that is was a
| minor bug.
| :)

Yes ... it's the kind of thing that won't show up as a real problem until the string sort and numeric sort diverge.

One of the improvements I will make is that MetacelloVersionNumber will not derive it's printString from it's version parts (which is done now). The printString will just be a string set at version number creation time...it's part of what will make arbitrary version formats work correctly.

Dale