[sugar] Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 7:47 PM, Benjamin M. Schwartz <
bmschwar at fas.harvard.edu> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jameson "Chema" Quinn wrote:
> | It is desirable for Sugar to be able to compare versions and
> | guess which one is newer.
>
> "Newer" means "more recent".  If this capability is important to you, then
> we may simply include a datestamp in each bundle, separate from the
> version.  However, I do not know of any planned Sugar feature that would
> require the ability to determine which bundle was created most recently.


I'm not sure that has to be what we mean by "newer", and if it is, we need
to find a better word.  Dates are *not* the criteria we want for newness.
Code maturity is closer to the intended meaning, and I think is the newness
that Jameson is also referring to.

>
> | If, as is the current plan, multiple versions of
> | an activity can coexist on an XO, it is reasonable to want sugar to
> present
> | these in some sane order, and possibly give hints and/or aid if the user
> | wants to update and/or garbage collect. Otherwise, we might as well just
> be
> | using activity hash, which can be calculated without being explicitly
> | included in activity.info.
>
> I favor including a version string with every bundle.  I favor displaying
> this string in places where it is needed to disambiguate multiple versions
> of an Activity.  I'm merely suggesting that the system not attempt to
> parse it.
>
> You mention ordering.  The Journal designs have long called for all
> columns to be sorted, with the user selecting the order of sorting
> precedence.  One intermediate position would be for the Version column to
> be sorted according to a best-effort ordering that attempts to do
> something sane when faced with any of the common version string
> conventions.
>

I guess the point here is that performing intelligent string comparisons on
several of these schemes requires parsing the string. ;)

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080714/fa10e300/attachment.html>