<div dir="ltr"><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div class="Ih2E3d">Jameson "Chema" Quinn wrote:<br>
| It is desirable for Sugar to be able to compare versions and<br>
| guess which one is newer.<br>
<br>
</div>"Newer" means "more recent". If this capability is important to you, then<br>
we may simply include a datestamp in each bundle, separate from the<br>
version. However, I do not know of any planned Sugar feature that would<br>
require the ability to determine which bundle was created most recently.</blockquote><div><br>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.<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;"><br>
<div class="Ih2E3d"><br>
| If, as is the current plan, multiple versions of<br>
| an activity can coexist on an XO, it is reasonable to want sugar to present<br>
| these in some sane order, and possibly give hints and/or aid if the user<br>
| wants to update and/or garbage collect. Otherwise, we might as well just be<br>
| using activity hash, which can be calculated without being explicitly<br>
| included in <a href="http://activity.info" target="_blank">activity.info</a>.<br>
<br>
</div>I favor including a version string with every bundle. I favor displaying<br>
this string in places where it is needed to disambiguate multiple versions<br>
of an Activity. I'm merely suggesting that the system not attempt to<br>
parse it.<br>
<br>
You mention ordering. The Journal designs have long called for all<br>
columns to be sorted, with the user selecting the order of sorting<br>
precedence. One intermediate position would be for the Version column to<br>
be sorted according to a best-effort ordering that attempts to do<br>
something sane when faced with any of the common version string conventions.</blockquote><div><br> Two use cases:<br><br>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).<br>
<br>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.<br>
<br>(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.)<br>
<br>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.<br>
</div></div><br></div>