[OpenAFS] Re: buildbot and packages

[Troy Benjegerdes]

> > And I don't think OS X can handle more than a certain number of version
> > segments, or something?
> 
> OSX is special, but, we already have the problem and define something
> special there.
> What we'd need to do is define everything as an dev version of
> whatever, but then the problem is
> you can only count up to 255. See the CFBundleVersion documentation here:
> http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KEXTConcept/Articles/infoplist_keys.html
> 
> We already limitedly work around this but this will mean stretching
> what those segments mean even further, because you
> get e.g. 1.6.2d(0 through 255) and then you are out of dev versions.
> So the script we distribute to decode panics will always
> need to be run where the kernel module came from, and the end-user

So are we ever going to have a situation where we have 255 nightly 
builds, and we do *not* release a minor update? (say 1.6.2 to 1.6.3?)

I would argue for a version scheme something like:

major.minor.subminor.daily-build-id

where if we ever hit more than 128 daily builds, we go ahead and 
bump the subminor version and promote the code for the daily build
with the least problems to make the next major.minor.subminor 'release'

Don't we have bigger problems if we run out of dev versions than
figuring out what an end-user is running?


Or maybe this:

1.8.(months since 1.8.0)d(daily builds)   .... Or pick quarters...
every three months we pick a date from master with the best test
results as a 'release', and we have a predictable release schedule.