> 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. > > - Eben >
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. 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.) 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. ... and cscott just wrote an email which says many of the same things. Jameson
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel