Jay,

I think an even clearer scheme would use the highest change set number in the third position. Thus, the 3.0 image I downloaded a few days ago would be 3.0.3414. In fact, at this point the 3.0 becomes mostly sugar coating since the change set number basically tells it all. While the increments one would see for packages on an ftp server would likely be greater than one, the size of the increment would suggest the degree of change. Additionally, since bugs are generally created or fixed by a particular change set, then information like "Oh, that was introduced/fixed/cleaned-up in change set 1234" would directly point one to images that did or did not have this attribute.

Cheers,
Bob


On Wed, 7 Feb 2001 09:21:05 -0500 "Jay Carlson" <nop at nop.com> wrote:
>Each bundle of updates released by SqCentral gets a minor rev number.  That
>means that we're at, uh, "3.0.1" now, right?  Anyway, minor revs then refer
>to particular offsets in the update stream.
>
>If I had write access to the update stream, this would be really easy to
>implement: issue a changeset that just bumped a minor rev counter after
>every update bundle.  As a bonus, the rev-to-update-number mapping becomes
>very easy because it's marked in-band.
>
>Nobody has to build packaged image/changes for every minor rev, but when
>they are built they're named properly.  So maybe uiuc archive has .ZIP files
>of "3.0.0", "3.0.1" and then "3.0.7".  I'm not asking for more frequent
>packaging---well, more to the point, I'm not volunteering to do it, either.
>:-)