[OpenAFS] Re: buildbot and packages

Derrick Brashear shadow@gmail.com
Mon, 17 Sep 2012 23:33:05 -0400


On Mon, Sep 17, 2012 at 6:12 PM, Andrew Deason <adeason@sinenomine.net> wrote:
>> On Mon, September 17, 2012 5:50 pm, Jeffrey Altman wrote:
>> > The challenge is how should version numbers be generated so that
>> > tonight's build will upgrade yesterday's build while not interfering
>> > with the stable release numbering.
>
> Ah, okay, I wasn't thinking of this as like an unstable "channel" for
> people to stick to, but that makes sense.
>
> On Mon, 17 Sep 2012 17:56:47 -0400
> "Derek Atkins" <derek@ihtfp.com> wrote:
>>
>> How about MAJOR.MINOR.PL.DATESTAMP?   E.g.   1.6.2.120917 This should
>> upgrade from 1.6.1, or even 1.6.2, but 1.6.3 should be "newer"
>>
>> Does this not work?
>
> That could interfere with versions like 1.6.2.1 that sometimes occur.
> Conceptually I could imagine something like maybe 1.6.2.0.120917, but I
> don't remember what all the various version rules are for deb and rpm.
> 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
there would need a kernel dev
kit for useful results. Otherwise, you submit a bug, and we tell you
we have no idea what you are running
and try again with a real build.



-- 
Derrick