On Mon, Sep 17, 2012 at 6:12 PM, Andrew Deason <[email protected]> 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" <[email protected]> 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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
