[Sugar-devel] Proposal of dotted activity version number
simon at schampijer.de
Thu Oct 7 02:40:09 EDT 2010
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
That page is outdated.
The proposal is laid out in Gonzalo's initial mail. Sorry for the confusion.
More information about the Sugar-devel