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

Reply via email to