[Sugar-devel] Proposal of dotted activity version number

[C. Scott Ananian]

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).  I
think that's exactly the wrong way to optimize.  Sugar doesn't need
yet another ad-hoc undocumented scheme.
  --scott

-- 
                         ( http://cscott.net/ )