On Wed, Oct 6, 2010 at 8:58 AM, Gonzalo Odiard <[email protected]> wrote:
> > > On Tue, Oct 5, 2010 at 9:49 PM, C. Scott Ananian <[email protected]>wrote: > >> If you're going to use something other than simple integers, I suggest >> either: >> >> a) a string of dotted integers. You should *always* be able to >> subdivide a release if necessary. >> Strings like "peru" belong (in my opinion) in release notes or the >> name of the activity or anywhere else. They don't tell you anything >> about version ordering. If the problem is that you can't put a new >> release between 0 and 1, why are you creating a system that causes the >> same problem, except between 0.0.0 and 0.0.1? >> >> > Yes, you are right. The string part don't tell us anything about version > ordering > The idea is use a string of dotted integers to indicate the order and the > string part only to indicate a customization. > Why? We have activity groups today for this. > Because a teacher, a kid or a technician from Uruguay can see Peru have a > customization, download, test and use. > But the customization part does not imply order because it's not logic use > the alphabetic order (Peru < Ruanda < Uruguay?) > Then I plan to ignore the customization when I compute the order. > > >> b) use the debian version numbering system *exactly*. It has been >> shown to work in the real world, and it is well documented. The >> current proposal is neither (yet). We do not need to burden the world >> with yet another ad-hoc numbering system. Please build on other >> people's work instead of re-inventing the wheel. Just because the >> debian system has features you don't *think* you need (yet) is not a >> reason to bypass it. There are great benefits to sharing a commons. >> >> > I agree with not reinvent the wheel, but not with using the debian > versions. Why not the Fedora, Gentoo or OSX? > If you want, we will be using the linux kernel numbering system :) > > > >> Of course, my preference is to keep the existing simple integers and >> solve the version precedence problem in other ways. Perhaps important >> activities should be encouraged to "count by ten" when increasing >> verson numbers -- or perhaps the tight dependency of Browse on a given >> Sugar version should be fixed. >> >> > Integer number does not solve the problems we have today. > Not the problems of the developers, but the downstreams. > I am working with OLPC fixing Browse in sugar 0.84. The version we are > using is Browse 108, but I cant release Browse 109 because already exists. > The same problem we have, will have Dextrose or anybody who maintains a > older branch. > I Agree, is a real problem that we have in deployments. > And "count by ten" it's not a good idea. > > > >> A truely forward-thinking replacement would replace the integer >> version numbers with a git-style version tree. Just say, "this >> activity replaces the activity bundle with manifest hash abcdef". >> That is more decentralized, and more accurate. Each activity >> could/should contain a list of URLs describing the canonical source >> for both itself (authoritative) and its (say) 10 immediate parents >> (non-authoritative). This proposal could be elaborated -- and it >> paves the way for a truely decentralized activity repository, where >> activities are created *and hosted* by children *on their own >> machines*. (Isn't this stil the vision of Sugar?) >> > > No. Git it's fantastic but it's not the solution to all. > That would be a clear example of "Second system effect" [1] > > Gonzalo > > > [1] http://en.wikipedia.org/wiki/Second-system_effect > > >> --scott >> _______________________________________________ >> Sugar-devel mailing list >> [email protected] >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 2 601 57 73 Interno 2228 E-mail : [email protected]
_______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
