[Sugar-devel] Proposal of dotted activity version number

Daniel Castelo dcastelo at plan.ceibal.edu.uy
Thu Oct 7 09:40:20 EDT 2010


On Wed, Oct 6, 2010 at 8:58 AM, Gonzalo Odiard <gonzalo at laptop.org> wrote:

>
>
> On Tue, Oct 5, 2010 at 9:49 PM, C. Scott Ananian <cscott at laptop.org>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
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> 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 : dcastelo at plan.ceibal.edu.uy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/private/sugar-devel/attachments/20101007/99e4e56e/attachment-0001.html>


More information about the Sugar-devel mailing list