[sugar] Activity versioning schema
Jameson "Chema" Quinn
jquinn at cs.oberlin.edu
Wed Jul 16 19:18:25 EDT 2008
>
> For these reasons, in my humble opinion, choosing our software packaging
> format and guidelines (of which version numbering is but a single
> aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an
> off-the-shelf format. (I wish that the reality were otherwise).
Absolutely agreed. Except the part where we can't choose a version format
without resolving all other issues. I think it is clear what we want from a
version format: some simple, human-readable, comparable numbers.
If we want anything more, it ceases to be a version format and inevitably
becomes something far more complex. Which we may decide to implement,
although in the conversations you reference I was the very one suggesting we
wanted more complex things sooner, and I was shot down, I think justly. The
use case for versions is NOT source control, or keeping a record of forking
history, or determining network interoperability, or determining Glucose
version interoperability, or determining of identity relations, or
determining journal instance interoperability.
All of those are separate issues we will face one day, sooner or later, and
I doubt we will even look at the version numbers in the solution to any of
those. Versions are JUST for human-readable distinctions between two
versions of the same activity [in the future, "the same" will imply
"signed"], with the ability for humans or Glucose to make a reasonable (not
bulletproof) inference about which one has the maturer code. I think that
the rpm solution is just that, a solution.
Note: regarding the fact that versions are useless for determining identity
(whether two xo's are identical): this is currently ALL we use versions for.
This is bug 7534, which I will now nominate for 8.2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080716/049c2225/attachment.html>
More information about the Devel
mailing list