<div dir="ltr"><br><div class="gmail_quote"><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><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>
<br>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.<br>
<br>...<br><br>and cscott just wrote an email which says many of the same things.<br><br>Jameson<br></div></div></div>