[Sugar-devel] Proposal of dotted activity version number

[C. Scott Ananian]

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?

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.

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.

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?)
 --scott