RE: Future of MARC::Lint
>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
Re: Future of MARC::Lint
On Thu, Dec 16, 2004 at 05:10:45PM -0600, Bryan Baldus wrote: > I hope to have time to work on this this weekend. The only changes I plan to > make to the current version are the DATA fixes described before (adding > 001-008 and correcting the valid/obsolete indicator values). I've downloaded > the most recent tag list, with update 4 (Oct. 2003). I planned on cleaning > that up and adding it to the DATA section for the first stand-alone release. > > Other than the readme (currently empty), is there anything else that would > prevent the current files in CVS from being released as the first CPAN > version? Before you update anything how about we do a release to CPAN of what we have right now? I've populated the README and changed the version to 1.39 to start with. > I haven't really looked around in my CVS client's settings--do most > have a way of telling the server what version to set/how much to > increment the version when a file is added/committed? The version is defined in the lib/MARC/Lint.pm file. Before releasing it this normally needs to be updated. It's often a good idea to 'tag' the project when you've got a release version. This way you can roll back to a previous version when necessary. Most CVS clients will support tagging. I tagged 1.39 as v1-39. > I would definitely need help in producing a release for CPAN. My SSH/CVS > clients are only available at home, which is an unreliable dial-up > connection, so I rarely log on there. My AIM client hasn't gotten much use > in the past few years, but perhaps now would be a good time to see if it > still runs. I think my username, if it still exists, is similar to my CPAN > e-mail address. 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. //Ed
RE: Future of MARC::Lint
On Thursday, December 16, 2004 4:05 PM, Ed Summers wrote: >It might be a good idea to release the current MARC::Lint as a separate >package to CPAN before releasing new versions. That way we have a baseline >to work from. >Bryan if you need help doing this for the first time (from SourceForge) let me >know and I'll give you a hand (inkdroid on AIM and Yahoo). I hope to have time to work on this this weekend. The only changes I plan to make to the current version are the DATA fixes described before (adding 001-008 and correcting the valid/obsolete indicator values). I've downloaded the most recent tag list, with update 4 (Oct. 2003). I planned on cleaning that up and adding it to the DATA section for the first stand-alone release. Other than the readme (currently empty), is there anything else that would prevent the current files in CVS from being released as the first CPAN version? I'm unclear on how version numbering will work. Should the first release (as given by the our $VERSION statement) be 1.38, as it is currently, updated to 1.39 to note the corrected/updated data, or to something else (1.00, though that might conflict with previous versions included with MARC::Record)? How do you maintain/contend with version numbers for releases compared with the version assigned by the CVS server? I haven't really looked around in my CVS client's settings--do most have a way of telling the server what version to set/how much to increment the version when a file is added/committed? I would definitely need help in producing a release for CPAN. My SSH/CVS clients are only available at home, which is an unreliable dial-up connection, so I rarely log on there. My AIM client hasn't gotten much use in the past few years, but perhaps now would be a good time to see if it still runs. I think my username, if it still exists, is similar to my CPAN e-mail address. On Thursday, December 16, 2004 4:01 PM, Andy Lester wrote: >I would see nothing wrong with gutting the checker entirely and redoing >how it works. I don't have immediate plans for gutting the checker, at least not in the near term (especially given my limited knowledge of perl). It seems to be working well enough for now. >I think you definitely will want to build that in from day one. Look at >the tidy project, which I've wrapped up in HTML::Tidy. That sounds like a good suggestion. Thank you for your assistance, Bryan Baldus [EMAIL PROTECTED] (work) [EMAIL PROTECTED] (home) http://home.inwave.com/eija
Re: Future of MARC::Lint
On Thu, Dec 16, 2004 at 04:00:34PM -0600, Andy Lester wrote: > If it's actually been removed from the MANIFEST and doesn't ship, then > that's a Bad Thing. I want to wait until there IS a replacement distro > available that I can point at. It might be a good idea to release the current MARC::Lint as a separate package to CPAN before releasing new versions. That way we have a baseline to work from. Bryan if you need help doing this for the first time (from SourceForge) let me know and I'll give you a hand (inkdroid on AIM and Yahoo). //Ed -- Ed Summers aim: inkdroid web: http://www.inkdroid.org Computers are useless--all they can give you are answers. [Pablo Picasso]
Re: Future of MARC::Lint
On Thu, Dec 16, 2004 at 08:17:11AM -0600, Bryan Baldus ([EMAIL PROTECTED]) wrote: > MARC::Lint has now been moved out of the MARC::Record distibution, in > anticipation of its release as a standalone package distribution. The > MARC::Doc::Tutorial needs to be updated to reflect the change. If it's actually been removed from the MANIFEST and doesn't ship, then that's a Bad Thing. I want to wait until there IS a replacement distro available that I can point at. > I plan on updating MARC::Lint in the next few months and am seeking advice > on how to proceed. The first version will differ little from the version > previously bundled with MARC::Record. I will be adding fields 001-008 to the > DATA section (thus allowing for check_xxx methods for those fields). I would see nothing wrong with gutting the checker entirely and redoing how it works. The way I implemented it in the first place was based on having that list in a pretty similar format that I copied out of the /Understanding MARC/ booklet that Follett Software publishes. > One of my concerns, as has been mentioned in the past, is whether adding > these specific checks to the main MARC::Lint module might pose problems for > those using the module. Perhaps a method could be added to allow individual > checks to be turned on and off easily, such as through a filter function? I think you definitely will want to build that in from day one. Look at the tidy project, which I've wrapped up in HTML::Tidy. It's a very simple wrapper without all the configurability of libtidy, and I get a request every week for that configurability. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
