Errr... I think we've suddenly jumped a stage. I'm certainly in favour of having the version field indicate the developement status of the code. I'm less certain about updating this automatically and/or frequently.
The way I see it, my main interest is: a) being able to distinguish between released and development code b) for development code, knowing which release it's based on.
I'm less worried about knowing exactly how far it's diverged from this "public" breakpoint.
So I'd be inclined to got for something like:
5.1.1 (released version) 5.1.1+CVS (V5-1-patches until) 5.1.2.pre1 (plus CVS until) 5.1.2.pre2 (plus CVS until) 5.1.2.rc1 (plus CVS until) 5.1.2 (released version)
Then immediately the 5.1.2 tarball is publically released, the patches branch would be updated to be 5.1.2+CVS and the cycle would start again. Most of these happen already - it would only need a single additional update to indicate the opening of the CVS development again.
This wouldn't distinguish between a pre-release tarball, and the subsequent developments of it, but I don't feel that's a significant problem. And it would certainly be manageable "by hand" without needing to automate the version updates.
I have a piece of what I think is portable C that searches through all the CVS/Entries to find the file with the newest timestamp. e.g from another project I haven't pulled for some time:
: ./genversion 2004/05/04:02:31:28UTC
That lets you exactly identify someone's version.
--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
