[sugar] Activity versioning schema

[Gary C Martin]

On 15 Jul 2008, at 20:15, Eben Eliason wrote:

> On Tue, Jul 15, 2008 at 2:57 PM, C. Scott Ananian  
> <cscott at laptop.org> wrote:
>
>> 2008/7/15 Jameson Chema Quinn <jquinn at cs.oberlin.edu>:
>>> If you have a better idea of how Glucose should handle these issues,
>> please
>>> share it. Simplifying assumptions are good, even if they're not 100%
>> valid.
>>
>> Versions in activity.info files are either plain integers, or
>> RPM-standard version strings, with no pretense that these correspond
>> in any way to sugar major releases or anything at all, except that
>> they are ordered: if the activity updater sees that you have version
>> N, and there is a version M announced[*] as compatible with your  
>> build
>> where M > N, then it will suggest that you upgrade to M.  All other
>> meanings are encoded with other mechanisms.
>> --scott
>>
>
> How can you argue this and still argue that we can get away with  
> integer
> version numbers?  According to this logic, a when brand new  
> activity(x) for
> OS(y) is released at time (t) and a bugfix activity(x+1) for OS(y-1)  
> is
> released at time (t+1), anyone on OS(y) is going to try to update to  
> the
> "newer", larger, activity(x+1) version, with none of the new features.


Random thought, should there be an additional .info line in addition  
to version, related just to release build compatibility? Version  
(activity_version) is just some sortable entity to be agreed, integer  
is fine with me (indicating the developers best and shiniest release  
effort to date). A new .info entry for release compatibility would be  
added (release_version) holding the Sugar version last tested against.  
Sugar auto updaters would assume compatibility based on >=  
release_version. Release_versions could be (more) easily extracted for  
auto update scripts (control panel) so as to download the best and  
latest compatible code.

--Gary