<br><br><div class="gmail_quote">On Mon, Jul 14, 2008 at 5:55 PM, Jameson Chema Quinn <<a href="mailto:jquinn@cs.oberlin.edu">jquinn@cs.oberlin.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr"><br><div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div class="gmail_quote"><div>I agree with the signature approach.  However, I don't really know what happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to coincide with the "level of newness".  This is something we will lose completely without a minor release number.  The logical assumption is that "the bigger the number, the better/newer it is", which is blatantly false when point releases are intermixed with brand new versions with ever-increasing version numbers.  I might decide I need to clear up space, and so delete versions 37 and 38, thinking I was keeping the latest and greatest version 39 and be quite disappointed.</div>


<div><br></div><font color="#888888"><div>- Eben</div></font></div>
</blockquote></div><div><br>This idea works well when developers time their new-features releases to coincide with Sucrose updates. It starts to break down when that does not hold - does version 3.x mean "runs on same Sucrose as 3.0" or "holds essentially the same feature-set as 3.0" or some combination of both? I think that Eben is assuming the former - that nobody would go back and release lower version numbers except in order to maintain system compatibility - but this conflicts with a common assumption that major version changes are synonymous with major new features.<br>

<br>Basically, there are two separate problems here, and we should not be solving them together. One is that the latest release may not be the greatest - because of bugfix releases. I agree with Eben's proposal of minor version numbers as a (totally optional) solution; as long as the minor/major separator is not a decimal separator (that is, [.,]), the meaning is pretty self-evident. (I think that : is the best candidate, by analogy with times and bible verses.) <br>
</div></div></div></blockquote><div><br></div><div>This is actually my primary concern.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr">
<div class="gmail_quote"><div>But the second problem is harder: how do you tell people which versions run on which Glucose. Any attempt to encode this implicitly in version numbers is, I think, bound to fail, and not too helpful anyway. The update_url solution for #4951 fixes the most useful version of this problem - "what is the latest working version on my system". I think we can live without a more general solution to "will version X run on system Y" - even though that means some ugly trial-and-error when sharing activities across Glucose versions.</div>
</div></div></blockquote><div><br></div><div>I don't expect to have any encoded info which makes this decidedly easy.  I just want a simple way to say that versions 3.x - 5.x work on  OS release 8.2.  Nothing in the bundle needs to indicate that specifically, but at least we'd have a way to easily document compatibilities. I understand what you mean in that activity cycles won't necessarily match OS cycles, and it's true.  It's possible for several releases to be "designed for" a single OS version, and likewise possible that a major activity version would span several OS versions.  I'm mostly trying to safegaurd against the possibility of future API or other incompatibilities which come from Sugar itself.  It would be up to the activity developer to decide if they wanted to jump to a new major version to support a new API or feature which isn't around in older versions of the OS.</div>
<div><br></div><div>- Eben</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr"><div class="gmail_quote"><div><br>
<br>...<br><br>and cscott just wrote an email which says many of the same things.<br><br>Jameson<br></div></div></div>
</blockquote></div><br>