[sugar] Activity versioning schema

[Jameson "Chema" Quinn]

-----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 misspoke. I meant, "the latest", in the same sense that Eben is using it:
the version with all relevant new feature decisions (including added and
dropped features) and bugfixes. This is not always the one created at the
latest calendar date.


>
> | 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.


 Two use cases:

1. I have a journal object. I want to choose which activity to open it with.
I am presented with a multilevel menu: the top level has all activities
which open the mime type, the next level has all major versions of those
activities, the next level minor versions, etc. If click without bothering
to move over to the sublevels, I get the default version from the sublevel
of my current menu, which is the starred version (if it exists) or the
highest version (applied recursively down the sublevels).

2. I just quit an activity version which is signed (ie, not just a
development build) and is a higher number than the starred version. A dialog
pops up asking if I want to "update" to that version. If I click yes, Sugar
moves the star to the new version (freeing the older version for possible
later GC). If I choose "no", the dialog will not appear again.

(Dealing with instances associated with the old version is more complicated.
Say I have an instance from Write 50 and Write 60 is starred. I suggest that
the ideal behaviour would be to open by default with Write 60, assuming it
handles the mime type, but ask after closing if that worked; if not,
remember that Write 50 instances may be incompatible with other versions and
open them by default with Write 50 always. An instance of Write 70 should
open with Write 70. This would not change GC behaviour: you might end up
GC-ing an old version and losing access to your instances, but the old
version would be available if necessary from the backup server.)

I guess you could argue that use case 2 should offer to assist downgrades as
well as upgrades (since we would be keeping separate already-showed-dialog
metadata for each version, any version would only show the dialog once, and
that would be more likely to be when it was newer), but I think that even
then it would be useful to include the words "higher version" or "lower
version" in the dialog.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080714/7f9617bd/attachment.html>