On Wed, Oct 6, 2010 at 5:00 PM, Martin Langhoff <martin.langh...@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/ ) _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel