FW: [Dbix-class] Module versioning

Duncan Garland Duncan.Garland at motortrak.com
Thu Apr 14 15:34:56 GMT 2011


Do we conclude from this that most people use RPMs?

-----Original Message-----
From: Robert Kinyon [mailto:rob.kinyon at gmail.com] 
Sent: 14 April 2011 16:31
To: Duncan Garland
Subject: Re: [Dbix-class] Module versioning

Defaults are just that - defaults. If your workflow needs something
else, then do that.

Rob

On Thu, Apr 14, 2011 at 11:23, Duncan Garland
<Duncan.Garland at motortrak.com> wrote:
> The default Catalyst make process uses CPAN. That's why we have been installing from CPAN. A major objective has been to keep to the defaults.
>
> The modules are different and they probably shouldn't be. We'll check the module versions higher up the dependency chain.
>
> -----Original Message-----
> From: Robert Kinyon [mailto:rob.kinyon at gmail.com]
> Sent: 14 April 2011 15:32
> To: DBIx::Class user and developer list
> Cc: Duncan Garland
> Subject: Re: [Dbix-class] Module versioning
>
> On Thu, Apr 14, 2011 at 09:51, Duncan Garland
> <Duncan.Garland at motortrak.com> wrote:
>> 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.
>
> You should be worried about distribution versions, not module
> versions. This is the sort of thing that rpm (and similar tools) was
> designed to solve. Nothing says you have to use the community RPMs. At
> $work, we build RPMs of the stuff we depend on. Then, we build RPMs of
> our stuff with dependencies on the RPMs we built of CPAN modules.
> Then, we have our own internal RPM repository that we deploy to prod
> from.
>
> That way, we control our upgrades, we know what we have where, and we
> don't worry about module $VERSION numbers.
>
> Rob
>



-- 
Thanks,
Rob Kinyon


More information about the DBIx-Class mailing list