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