"Thomas A. Lowery" wrote:

> I've changed my version of DBD::ADO to 2.0, instead of continuing the
> 1.X line.  This may help in future releases.
>
> > > Why did the version regress?  Let's take a look at the code for
> > > blib/DBD/ADO.pm in DBI 1.15 and 1.14:
>
> Tim and I we're attempting to maintain DBD::ADO is two different CVS
> libraries I believe.
> Now, my question:  Is this the standard "version" syntax?
>         $VERSION = substr(q$Revision: 2.0 $, 9,-1) +0;

It's one variation on a fairly common theme.

It's not the way I do it with DBD::Informix, but then that's like nothing else as
far as I can tell.  One added complexity is that DBD::Informix is under ClearCase
and ClearCase studiously refuses to believe that source code can ever be accessed
without a VOB so you don't need to embed version information into a file.
Bullshit, as you might say.  Anyway, I make a copy of the files, and version
stamp each file with the file's version information extracted from ClearCase and
(separately) with the version of DBD::Informix as a whole.

> using: perl -MDBD::ADO -e "print $DBD::ADO::VERSION"
> I get 2
>
> Is there a better method?
>
> Attached is my latest version.  Only a few minor differences from the
> CPAN version.
>
> Maybe I should release DBD::ADO as a CPAN module as it's grown, and
> really only applies to Win32 systems (AFAIK).  Opinions?
> Then if you, Tim, still want to continue including it with the DBI release,
> you'd just need to pull the current CPAN version.

My inclination is to suggest that all the real database drivers (meaning all
except Sponge and Example and any other similar ones I've forgotten) should be
separately downloaded modules.  In some respects, I suspect the the DBI Proxy
code should be separate too, and the DBI Shell...

--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED])
Guardian of DBD::Informix 1.00.PC1 -- see http://www.cpan.org/
#include <disclaimer.h>


Reply via email to