On Mon, September 17, 2012 5:50 pm, Jeffrey Altman wrote:
> On 9/17/2012 5:41 PM, Andrew Deason wrote:
>
>> Isn't this what we already have? If you have a source tree that's not
>> exactly the commit for e.g. openafs-stable-1_6_1, you get a string
>> saying how many commits you are from a known point, and a git hash. So,
>> we should be able to identify exactly what build something came from,
>> with the existing versioning code, unless I'm mistaken here.
>
> 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.
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?
-derek
--
Derek Atkins 617-623-3745
[email protected] www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info