On 15 Jul 2008, at 20:15, Eben Eliason wrote: > On Tue, Jul 15, 2008 at 2:57 PM, C. Scott Ananian > <[EMAIL PROTECTED]> wrote: > >> 2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>: >>> 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 _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar