>>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.
>
>
> Thanks for the offer - and if we do go down this road, that might well
> be worth looking at. But I remain unconvinced that it's necessary for
> the version string to include a timestamp at all.
>
> I still feel that a plain "5.1.1+CVS" style would be sufficient.
>
> Particularly if we can be a little more successful at rolling out
> minor releases at more frequent intervals.
>
> If the version stamp is updated frequently (e.g. daily or for every commit),
> that just adds extra noise to the CVS logs (mailing list, ChangeLog,etc)
> for no real significant benefit, IMO.
> And if it's not going to be frequent, then why bother?
>
> Not to mention that any form of automated update is an extra
> potential source of problems.
>
> This may be partly why Robert got the impression that he was alone in
> wanting a change, I suppose. I'm generally against the idea of automated
> updates - I don't trust computers :-)
> But a simple manual mechanism should be both reliable and useful.
: cvs -q update -Dp : ./local/Version-Munge.pl -M -v "5.1 CVS `./genversion`" : make : ./apps/snmpget -V NET-SNMP version: 5.1 CVS 2004:06:27:06:40:49UTC
If it wasn't CVS HEAD it would have a tag after UTC.
-- 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