I don't see why this needs to be kept in CVS. It should be generated when you build.
Just to check - what do you mean by "it" here?
There should be a version in exactly one place. I'd suggest that in CVS it should indicate the version as which CVS will be released.
At the moment the version is hard coded in snmplib/snmp_version.c, README, FAQ, dist/net-snmp.spec, sedscript.in, dist/Makefile, doxygen.conf, perl/SNMP/SNMP.pm, perl/agent/agent.pm, perl/agent/default_store/default_store.pm, perl/default_store/default_store.pm, perl/OID/OID.pm, perl/ASN/ASN.pm, perl/AnyData_SNMP/Storage.pm, perl/AnyData_SNMP/Format.pm, and perl/TrapReceiver/TrapReceiver.pm
Having make insert where required sounds more civilised.
The base version tag, the fact that this code tree is a CVS development version, or the precise date it was checked out?
The base version needs to come from *somewhere*. And that "somewhere" needs to be in the CVS system, so it can be updated when we make a new release.
I can see the attraction of adding a timestamp automatically as part of configuring the software, but this shouldn't touch the source of the base version tag. Otherwise it just takes one moment of inattention from one of the developers when committing a change, and Shield's screwed up the CVS tree yet again :-(
So it should be generated into files which gets .cvsignore'd
The only issue with using local/Version-Munge.pl is that the files on which it operates are in CVS. The way to go might be to have *.in files that get munged or have make pass the version where-ever required. I like the *.in solution.
It probably doesn't matter too much whether the ".cvs" tag is part of the base version (and updated by hand) or added automatically. But it feels safer (and somewhat simpler) to do it by hand, since that doesn't need any new code.
But I'd tend to agree that adding a timestamp (or similar serial number) would probably be better done "outside" CVS.
-- 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
