<div class="gmail_quote">On Tue, Jul 15, 2008 at 2:57 PM, C. Scott Ananian <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 2008/7/15 Jameson Chema Quinn <<a href="mailto:jquinn@cs.oberlin.edu">jquinn@cs.oberlin.edu</a>>:<br> <div class="Ih2E3d">> If you have a better idea of how Glucose should handle these issues, please<br> > share it. Simplifying assumptions are good, even if they're not 100% valid.<br> <br> </div>Versions in <a href="http://activity.info" target="_blank">activity.info</a> files are either plain integers, or<br> RPM-standard version strings, with no pretense that these correspond<br> in any way to sugar major releases or anything at all, except that<br> they are ordered: if the activity updater sees that you have version<br> N, and there is a version M announced[*] as compatible with your build<br> where M > N, then it will suggest that you upgrade to M.  All other<br> meanings are encoded with other mechanisms.<br>  --scott<br></blockquote><div><br></div><div>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.</div> <div><br></div><div>- Eben</div></div>