[Catalyst] Managing module regressions.

Fred Moyer fred at redhotpenguin.com
Tue Jul 24 20:27:51 GMT 2012


On Tue, Jul 24, 2012 at 1:03 PM, Tomas Doran <bobtfish at bobtfish.net> wrote:
>
> On 24 Jul 2012, at 19:17, Fred Moyer wrote:
>> Also, these experiences are that of a large team developing large apps
>> to hundreds of servers. The experience of one developer deploying to a
>> small environment will certainly be different.
>
>
> I wonder how life would be different if you just deployed an entire perlbrew per app, so /opt/MyApp/bin/perl - this would make the cost of upgrading things much more trivial, as the cost would be per project, rather than having a wider impact.. It would also allow teams for each product to be strongly conservative (if that suited the team in question), or running much newer versions of stuff (on younger apps / more agile teams) - rather than having to dictate a version policy organisation wide.

Agreed on the heterogenous module approach for different apps.  That
part of it has worked well, but sometimes dependencies leak up the
chain into your application. It's definitely not an easy problem. So
far though I think we've had success in the current approach despite
the pain points on certain part.

>
> I'm _not_ saying it would be better - everyone's environment and constraints are different, but thinking 'what if' about an entirely different strategy is entirely worthwhile. A lot of your pain seems to come from the fact that you can only have one version of every library on each system.
>
> Cheers
> t0m
>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/



More information about the Catalyst mailing list