[Sugar-devel] Proposal of dotted activity version number

[Simon Schampijer]

On 10/06/2010 11:15 PM, C. Scott Ananian wrote:
> On Wed, Oct 6, 2010 at 5:00 PM, Martin Langhoff
> <martin.langhoff at gmail.com>  wrote:
>> Initially, I advocated strongly for something with the expresiveness
>> of dpkg's versioning. However, that's wrong. We need to use a clear
>> _subset_ of what dpkg, rpm, portage(... etc) can do, so the distro
>> packager retains its flexibility (see: epoch).
>
> Defining the version string as "identical to the pre-epoch portion of
> a debian version string" says a lot more in 11 words -- and with more
> precision -- than the entirely of the dotted version string proposal
> so far.  This is the power we get from *building* on other's work,
> instead of reinventing it.  (But we should remember what problem
> debian is solving with epoch numbers, and think really hard about why
> this could never ever ever happen to us before getting rid of them.)
>
> You could make a similar proposal based on redhat version strings,
> etc.  We all *think* we need a subset right now.  And then you'll find
> that subset grow, and mutate, etc, etc.  We are all better off if we
> implement a well understood standard, even if we don't think we need
> all of its power immediately.
>
>> It is true, dpkg considers 1.1-peru to be an upgrade over
>> 1.1-argentina, due to alpha ordering. But that has no useful meaning.
>
> My personal feeling is that the "peru" and "argentina" part isn't
> really a version number, it's something else, which is misplaced here.
>   But I don't feel as strongly about that.
>
>>> Either solve the problem correctly, or solve it as simply as possible.
>>
>> This solves it as simply as possible.
>
> I've outlined several simpler solutions.  QED.
>
> Again, I think either the slightly more complicated (but more precise
> and easier to describe) solution ("debian version numbers, exactly"),
> or a simpler solution (say, "just use only even version numbers for
> upstream releases, save odd numbers for localization teams") is
> preferred to the present proposal, which I think is both too
> complicated (by defining its own ad-hoc version string semantics) and
> too simple (0.1 possible, 0.0.1 impossible, at least according
> tohttp://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions).

That page is outdated.

The proposal is laid out in Gonzalo's initial mail. Sorry for the confusion.

Regards,
    Simon