Re: Maintaining an Enterprise Perl Distribution

Didn't we run into a problem with a module that was upgraded and changed behaviour on us? :)

Before you upgrade, you can use your development servers to make sure everything works with the new versions, so that's already a leg up on what most people have.

I definitely recommend staying away from anything that smells like early-adopter. I tend to think that old code does the same thing that it always did, and if old code is working and you have other things to think about, other things should win. Other people in Stonehenge are at the other end of the spectrum. :)

--
brian d foy <bdfoy@cpan.org>

Comment on Re: Maintaining an Enterprise Perl Distribution

Replies are listed 'Best First'.
Re^2: Maintaining an Enterprise Perl Distribution by cbrandtbuffalo (Deacon) on Mar 25, 2005 at 13:06 UTC
Yes, we did. I think it was the URI module. It changed how it translated some things in the uri_escape method. This is one of my bigger fears. Module authors can change behavior, or even just change a default setting. If we have code that relied on this default, it might break. Actually, I think DBI changed a default in a somewhat recent update and I've got it on my list as something that might break. The safe thing here is to check for the know changes before the update, but I don't relish going through the change notes for every module we have installed to see if they changed a key behavior or setting. But if we want to know what we're getting into, this may be necessary. I have a script to report what code is using what module. For modules that only have one user, I guess I could get that developer to look into things. My problem there is that too often I was 'that developer' who recommended using a module. :)	[reply]

Replies are listed 'Best First'.

Re^2: Maintaining an Enterprise Perl Distribution
by cbrandtbuffalo (Deacon) on Mar 25, 2005 at 13:06 UTC

This is one of my bigger fears. Module authors can change behavior, or even just change a default setting. If we have code that relied on this default, it might break. Actually, I think DBI changed a default in a somewhat recent update and I've got it on my list as something that might break.

The safe thing here is to check for the know changes before the update, but I don't relish going through the change notes for every module we have installed to see if they changed a key behavior or setting. But if we want to know what we're getting into, this may be necessary.

I have a script to report what code is using what module. For modules that only have one user, I guess I could get that developer to look into things. My problem there is that too often I was 'that developer' who recommended using a module. :)

[reply]