[Dbix-class] Module versioning

[Duncan Garland]

Hi Peter,

There isn't necessarily a specific problem with that module. It's just an example of a module which is different between two of our systems.
One uses OracleHacks and one doesn't.

Those modules are unversioned, but the top-level DBIx::Class module is versioned. Perhaps bringing the top modules into line will bring the
whole tree into line.

The general problem is that since we've started using Catalyst and DBIx we've become reliant on a dependency chain of over a thousand modules. This has exposed the fact that our housekeeping isn't as good as it should be.

I was wondering how other people approach this problem.

Regards

Duncan
-----Original Message-----
From: Peter Rabbitson [mailto:rabbit+dbic at rabbit.us] 
Sent: 14 April 2011 17:35
To: Class user and developer list
Subject: Re: [Dbix-class] Module versioning

Duncan Garland wrote:
> Hi,
> 
>  
> 
> What’s the most common/best method of keeping the modules consistent 
> between systems? Since we joined the Catalyst/DBIx community we’ve 
> become much more dependent on that
> 
> sort of thing.
> 
>  
> 
> We assumed that just keeping  Makefile.PL up to date but that doesn’t 
> seem to be enough on its own the our various platforms seem to be different.
> 

What is your actual problem?

>  
> 
> Some of the DBIx modules do not have version numbers (eg 
> DBIx::Class::Storage::DBI::Oracle::Generic.pm) so I’m not sure how the 
> dependency chain is supposed to work.

Again - a version in individual modules is not mandatory (and in fact
is frowned upon by some). Please describe your problem so that we
have a proper context to answer your question.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk