>Ok, in that case I'll upload 1.39 myself and make you a maintainer. This >way the MARC::Record distribution can reference MARC::Lint if necessary, >and you'll have a baseline version to move forward from.
That sounds good. I thought I had version 1.40, with updated DATA (to update #4, Oct. 2003) section ready for committing, but there seems to be a problem somewhere in the data I added. I keep getting a message "630: Indicator 1 must be blank but it's "0"". Deleting the 630 entry in the DATA causes a new error, with 611 indicators. Once I figure out what went wrong and fix it, I should be ready to commit the updated file (this weekend, or when it is safe/ok to do so). I may have added some spaces where they didn't belong. >It's often a good idea to 'tag' the project when you've got a release version. This is probably explained somewhere in CVS documentation (which I'll eventually get around to reading, along with SourceForge's release system guide), but is tagging done on a file level or a full project level? Does tagging occur just before a release, or should I tag the new 1.40 version of MARC::Lint.pm as v1-40 when I commit it for the first time? If I would like to add directories/files to CVS (MARC::Lint::CodeData, a TODO file, updates to the test and specs scripts (including cross-platform compatibility via File::Spec), along with general file update committing, is it safe/ok to do so? Is it possible to selectively not include files in release versions of the package project (for example, put CodeData in CVS in anticipation of future use, but not release it with v. 1.40 or later, until it is actually needed by MARC::Lint)? Thank you for your assistance, Bryan Baldus [EMAIL PROTECTED] [EMAIL PROTECTED] http://home.inwave.com/eija
