[OpenAFS-devel] OpenAFS 1.2.10 Release Candidate 1 now available for testing

[Alexei Kosut]

On Fri, Jun 06, 2003 at 03:40:07PM -0400, Derrick J Brashear wrote:
> > Would 1.2.A work?  Or must it be digit?

No, it must be a digit.

> Some better fix would be nice, because even hex doesn't help e.g. 1.3.50

Exactly.

I've looked at the Darwin sources, and here are some more details:
Internally, IOKit parses the string from the CFBundleVersion property
into a 32-bit integer value using a format very similar to (although
not exactly the same as) the Mac OS 9 'vers' resource structure.  See
<http://developer.apple.com/technotes/tn/tn1132.html> for details, but
the salient point is that the numeric part of the version uses
binary-coded decimal, with one byte for the major revision and another
byte shared between the minor and "bug revision" values.  For example,
1.2.9 is encoded as 0x0129.

Technically, you could encode 1.2.10 as 0x012A, but the function that
generates these values from the strings (VERS_parse_string() in
vers_rsrc.c) does not do this.  And, as Derrick points out, it
wouldn't help us for 1.2.16.

I've filed a bug with Apple about this (Problem ID #3282776), but even
if they fix it, it doesn't help with existing OS releases.

The best I've been able to come up with is to use the 'revision level'
part of the version string to store the patchlevel instead of the 'bug
revision' part.  So instead of calling it "1.2.10", we could use
"1.2fc10".  The revision level can range from 1-255, so that would
work for some time.

This at least has the advantage that a human can look at "1.2fc10" and
understand that it bears some similarly to 1.2.10.  This is especially
relevant to us at Stanford, since part of our Mac OS X GUI displays
the OpenAFS revision to the user using the kernel extension version.
(Although we could easily change our code to look elsewhere.)

The one problem with this scheme is that 1.2fc10 encodes to
0x0120700A, while 1.2.9 (the current release) encodes as 0x01298000.
Darwin treats these as directly-comparable 32-bit integers when
looking at dependencies.  So if another kernel extension depends on
version "1.2.9" of OpenAFS, "1.2fc10" will not satisfy that
dependency.  Conversely, if an extension has a dependency on
"1.2fc10", that would be satisfied by "1.2.9" (or even "1.2.0").

However, I'm not aware of any other kernel extensions that depend on
OpenAFS, so this is probably our best bet, assuming it's possible to
write an autoconf macro to convert @VERSION@ into this format.

-- 
Alexei Kosut <akosut@cs.stanford.edu> <http://cs.stanford.edu/~akosut/>